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FOREWORD 


1 .  This  standard  defines  the  Government’s  requirements  and  expectations  for  contractor 
performance  in  defense  system  acquisitions  and  technology  developments. 

2.  This  new-issue  SMC  standard  comprises  the  text  of  The  Aerospace  Corporation  report 
number  TOR-2006(8583)-1. 

3.  Beneficial  comments  (recommendations,  additions,  deletions)  and  any  pertinent  data  that 
may  be  of  use  in  improving  this  document  should  be  documented  on  a  Standardization  Document 
Improvement  Proposal  appearing  at  the  end  of  this  document  or  by  letter.  All  proposals  for 
changes  shall  be  addressed  to 


Division  Chief,  SMC/EAE 
SPACE  AND  MISSILE  SYSTEMS  CENTER 
Air  Force  Space  Command 
483  N.  Aviation  Blvd. 

El  Segundo,  CA  90245 

4.  This  standard  has  been  approved  for  use  on  all  new  SMC/AFPEO-Space  development, 
acquisition,  and  sustainment  contracts,  including  new  contracts  for  legacy  programs: 


Col  James  Horejsi,  USAF 
SMC  Chief  Engineer 
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1.0 


SCOPE. 


This  document  defines  configuration  management  requirements  which  are  to  be  selectively  applied,  as  required, 
throughout  the  life  cycle  of  any  configuration  item  (Cl): 

a.  Developed  wholly  or  partially  with  Government  funds,  including  non-developmental  items  when  the 
development  of  technical  data  is  required  to  support  off-the-shelf  equipment  or  software,  or 

b.  Designated  for  configuration  management  for  reason  of  integration,  logistics  support,  or  interface 
control. 

1.1  Applicability 

This  standard  applies  to  Space  and  Missile  Systems  Center  Los  Angeles  Air  Force  Base  activities  and 
contractors  who  are  tasked  with  the  application  of  configuration  management 

1.2  Government  Tailoring  of  requirements. 

This  standard  is  applicable  only  to  the  extent  specified  in  the  tasking  directive  or  contract  Statement  of  Work 
(SOW).  Contracts  invoking  this  standard  will  specifically  identify  the  appropriate  applicable  paragraphs  and 
Appendices,  or  portions  thereof,  in  the  tasking  directive  or  contract  SOW.  The  selection  of  necessary 
configuration  management  requirements  from  this  standard  to  be  applied  to  a  specific  program  will  be  tailored 
by  the  government  to  suit  the  life-cycle  phase,  complexity,  size,  intended  use  (including  joint  and  combined 
interoperability) ,  mission  '  criticality,  and  logistics  support  of  the  CIs. 
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2.0 


APPLICABLE  DOCUMENTS 


Usage  Note:  Latest  version  unless  otherwise  indicated. 

MIL-STD-1388-1  Logistic  Support  Analysis  (Superseded  [S/S]  by  Mil-Hdbk-502) 

MIL-STD  -1388-2,  DoD  Requirements  for  a  Logistic  Support  Analysis  Record  (S/S  By  Mil-Prf-49506) 

MIL-STD-280  Definitions  Of  Item  Levels,  Item  Exchangeability,  Models,  And  Related  Terms  (S/S 

By  Mil-Hdbk-505) 

MIL-STD- 1520  Corrective  Action  And  Disposition  System  For  Nonconforming  Material  (No  S/S 

Document) 

MIL-STD-961  Defense  And  Program-Unique  Specifications  Format  And  Content 

MIL-STD-881  Work  Breakdown  Structures  For  Defense  Material  Items  (S/S  By  Mil-Hdbk-881) 

MIL-STD-973  Configuration  Management  (No  S/S  Document) 

MIL-STD-130  Identification  Marking  of  US  Military  Property 

MIL-STD-882  System  Safety 

MIL-STD-965  Parts  Control  Program  (S/S  By  Mil-Hdbk-965) 

MIL-HDBK-881  Work  Breakdown  Structures  for  Defense  Materiel  Items 

MIL-P- 15024  Plates,  Tags  and  Bands  for  Identification  of  Equipment 

ASME  Y  14.100  Engineering  Drawing  Practices 

IEEE  STD  610.12  Glossary  of  Software  Engineering  Terminology,  September  28,1990 

ISO/IEC  12207  Software  Life  Cycle  Processes 

SD-2  Non-developmental  Item  Program 

Title  10  United  States  Code,  Section  2302,  “Definitions” 
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3.0 


ACRONYMS 


3.1  Acronyms  used  in  this  standard. 

The  acronyms  used  in  this  TOR  are  defined  as  follows: 


ABL 

ACD 

AIS 

AMSDL 

CAGE 

CAO 

CCB 

CDR 

CDRL 

Cl 

CM 

CSA 

CSAR 

CSCI 

DID 

DLA 

DOD 

DODAAC 

DODISS 

DUI 

ECP 

EMD 

FBL 

FCA 

FSD 

GFD 

GFE 

HWCI 

ICD 

ICWG 

IDD 

ILS 

IRS 

LSA 

MRB 

MTS 

NDI 

NOR 

NSN 

PBL 

PCA 

PCD 

PDI 

PDR 

PPSL 

RFD 

SPS 

SDL 

SCN 

SMC 


Allocated  Baseline 

Allocated  Configuration  Documentation 
Automated  Information  System 

Acquisition  Management  Systems  and  Data  Requirements  Control  List 

Commercial  and  Government  Entity 

Contract  Administration  Office 

Configuration  Control  Board 

Critical  Design  Review 

Contract  Data  Requirements  List 

Configuration  Item 

Configuration  Management 

Configuration  Status  Accounting 

Configuration  Status  Accounting  Report 

Computer  Software  Configuration  Item 

Data  Item  Description 

Defense  Logistics  Agency 

Department  of  Defense 

Department  of  Defense  Activity  Address  Code 

Department  of  Defense  Index  of  Specifications  and  Standards 

Data  Use  Identifier 

Engineering  Change  Proposal 

Engineering  and  Manufacturing  Development 

Functional  Baseline 

Functional  Configuration  Audit 

Functional  Configuration  Documentation 

Government  Furnished  Data 

Government  Furnished  Equipment 

Hardware  Configuration  Item 

Interface  Control  Drawing 

Interface  Control  Working  Group 

Interface  Design  Document 

Integrated  Logistics  Support 

Interface  Requirements  Specification 

Logistics  Support  Analysis 

Material  Review  Board 

Mobile  Training  Sets 

Non-Developmental  Item 

Notice  of  Revision 

National  Stock  Number 

Product  Baseline 

Physical  Configuration  Audit 

Product  Configuration  Documentation 

Privately  Developed  Item 

Preliminary  Design  Review 

Program  Parts  Selection  List 

Request  For  Deviation 

Software  Product  Specification 

Software  Development  Libraiy 

Specification  Change  Notice 

Space  and  Missile  Center 
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SOW 

Statement  of  Work 

TCTO 

Time  Compliance  Technical  Order 

TRR 

Test  Readiness  Review 

VDD 

Version  Description  Document 

VE 

Value  Engineering 

VECP 

Value  Engineering  Change  Proposal 

WBS 

Work  Breakdown  Structure 

3.2 

DEFINITIONS 

Allocated  Baseline  (ABL).  The  approved  allocated  (design-to)  configuration  documentation. 

Allocated  Configuration  Documentation  (ACD).  The  documentation  describing  a  Cl’s  functional,  performance, 
interoperability,  and  interface  requirements  that  are  allocated  from  those  of  a  system  or  higher  level 
configuration  item;  interface  requirements  with  interfacing  configuration  items;  and  the  verifications  required  to 
confirm  the  achievement  of  those  specified  requirements. 

Approval/contractual  implementation.  The  acceptance  by  the  Government  of  a  document  as  complete  and 
suitable  for  its  intended  use.  Approval/contractual  implementation  of  configuration  documentation  means  that 
the  approved  documentation  is  subject  to  the  Government’s  configuration  control  procedures. 

Audit.  An  independent  evaluation  conducted  by  authorized  persons. 

Baseline.  A  formally  approved  version  of  a  configuration  item,  regardless  of  media,  formally  designated  and 
fixed  at  a  specific  time  during  the  configuration  item’s  life  cycle.  (Source:  ISO/IEC  12207) 

Block  change  concept.  For  hardware  configuration  items,  an  engineering  change  implementation  concept  that 
designates  a  number  (i.e.,  a  block)  of  consecutive  production  units  the  configuration  item  to  have  an  identical 
configuration  on  delivery  and  in  operation.  (Using  this  concept,  the  production  run  is  divided  into  “blocks”  of 
units.  The  production  line  incorporation  point  for  a  proposed  ECP  is  delayed  to  coincide  with  the  first  unit  of 
the  next  block,  or  retrofit  is  required  at  least  for  all  already  delivered  units  of  the  current  block.)  For  computer 
software  configuration  items,  once  the  product  baseline  has  been  established,  the  concept  requires  the 
accumulation  and  the  simultaneous  implementation  of  a  number  of  routine  software  changes  to  minimize  the 
number  of  interim  versions  and  related  documentation. 

Classification  of  defects.  The  enumeration  of  possible  defects  of  the  unit  or  product,  classified  according  to  their 
seriousness.  Defects  will  normally  be  grouped  into  the  classes  (e.g.  orthogonal  defect  classification  for 
software)  of  critical,  major  or  minor:  however,  they  may  be  grouped  into  other  classes,  or  into  subclasses  within 
these  classes.  (Source:  MIL-STD-109) 

Commercial  and  Government  Entity  (CAGE)  Code.  A  five  position  alphanumeric  code  with  a  numeric  in  the 
first  and  last  positions  (e.g.,  27340,  2A345,  2AA45,  2AAA5),  assigned  to  United  States  and  Canadian 
organizations  which  manufacture  and/or  control  the  design  of  items  supplied  to  a  Government  Military  or  Civil 
Agency  or  assigned  to  United  States  and  foreign  organizations,  primarily  for  identifying  contractors  in  the 
mechanical  interchange  of  data  required  by  MILSCAP  and  the  Service/Agency  Automated  Data  Processing 
(ADP)  systems. 

Computer  database.  See  “database”. 

Computer  software.  See  ‘software”. 

Computer  Software  Configuration  Item  (CSCI).  An  aggregate  of  software  that  satisfies  an  end  use  function  and 
is  designated  for  purposes  of  specification,  interfacing,  qualification  testing,  configuration  management,  or 
other  purposes.  CSCIs  are  selected  based  on  tradeoffs  among  software  function,  size,  host  or  target  computers, 
developer,  support  strategies,  plans  for  reuse,  criticality,  interface  considerations,  the  need  to  be  separately 
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documented  and  controlled,  and  other  factors.  A  CSCI  is  composed  of  one  or  more  software  units.  A  computer 
software  configuration  item  (CSCI)  may  also  be  interchangeably  termed  as  software  item  (SI). 

Computer  software  documentation.  Technical  data  or  information,  regardless  of  media,  which  documents  the 
requirements,  design,  or  details  of  computer  software;  explains  the  capabilities  and  limitations  of  the  software; 
or  provides  operating  instructions  for  using  or  supporting  computer  software  during  the  software’s  operational 
life  cycle. 

Computer  software  unit  (CSU).  See  software  unit. 

Configuration.  For  purposes  of  this  standard,  the  functional  and  physical  characteristics  of  existing  or  planned 
hardware,  firmware,  or  software  or  a  combination  thereof  as  set  forth  in  technical  documentation  and  ultimately 
achieved  in  a  product. 

Configuration  audit.  See  “Functional  configuration  audit”  and  “Physical  configuration  audit”. 

Configuration  baseline.  Configuration  documentation  formally  designated  by  the  Government  at  a  specific  time 
during  a  Cl’s  life  cycle.  Configuration  documentation,  plus  approved  changes  from  that  documentation, 
constitute  the  current  approved  configuration  baseline.  There  can  be  three  formally  designated  configuration 
baselines  in  the  life  cycle  of  a  configuration  item,  the  functional,  allocated,  and  product  baselines. 

Configuration  control.  The  systematic  proposal,  justification,  evaluation,  coordination,  approval  or  disapproval 
of  proposed  changes,  and  the  implementation  of  all  approved  changes,  in  the  configuration  of  a  Cl  after 
establishment  of  the  configuration  baseline(s)  for  the  CL 

Configuration  Control  Board  (CCB).  A  board  composed  of  technical  and  administrative  representatives  who 
recommend  approval  or  disapproval  of  proposed  engineering  changes  to  a  Cl’s  current  approved  and  baselined 
configuration  documentation.  The  board  also  recommends  approval  or  disapproval  of  proposed  deviations  from 
a  Cl’s  current  approved  and  baselined  configuration  documentation. 

Configuration  documentation.  The  technical  documentation,  including  architectural  and  design  products,  that 
identifies  and  defines  the  item’s  functional  and  physical  characteristics.  The  configuration  documentation  is 
developed,  approved,  and  maintained  through  three  distinct  evolutionary  increasing  levels  of  detail.  The  three 
levels  of  configuration  documentation  are  the  functional  (build-to)  configuration  documentation,  the  allocated 
(design-to)  configuration  documentation,  and  the  product  (as-built)  configuration  documentation. 

Configuration  identification.  Configuration  identification  includes  the  selection  of  CIs;  the  determination  of  the 
types  of  configuration  documentation  required  for  each  Cl;  the  issuance  of  numbers  and  other  identifiers  affixed 
to  the  Cl  and  to  the  technical  documentation  that  defines  that  Cl’s  configuration,  including  internal  and  external 
interfaces;  the  release  of  CIs  and  their  associated  configuration  documentation;  and  the  establishment  of 
configuration  baselines  for  CIs. 

Configuration  Item  (Cl).  A  configuration  item  is  an  aggregation  of  hardware  and  /or  software  and/or  firmware 
that  satisfies  an  end  use  function  and  is  designated  by  the  Government  for  separate  configuration  management. 
[Note:  Initially,  depending  on  the  level  to  which  the  Government  is  intending  to  conduct  baseline  control, 
developing  contractors  may  define/propose  their  configuration  items  and  provide  them  to  the  Government  for 
approval.  The  Government  may  then  approve  those  configuration  items  or  give  the  contractor  formal  direction 
to  change  them.] 

Configuration  Management  (CM). 

a)  As  applied  to  configuration  items,  a  discipline  applying  technical  and  administrative  direction  and 
surveillance  over  the  life  cycle  of  items  to: 

(1)  Identify  and  document  the  functional  and  physical  characteristics  of  configuration  items. 

(2)  Control  changes  to  configuration  items  and  their  related  documentation. 

(3)  Record  and  report  information  needed  to  manage  configuration  items  effectively,  including  the 
status  of  proposed  changes  and  implementation  status  of  approved  changes. 
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(4)  Audit  configuration  items  to  verify  conformance  to  specifications,  drawings,  interface  control 
documents,  and  other  contract  requirements. 

b).  As  applied  to  digital  data  files,  the  application  of  selected  configuration  identification  and  configuration 
status  accounting  principles  to: 

(1)  Uniquely  identify  the  digital  data  files,  including  versions  of  the  files  and  their  status  (e.g.,  working 
released,  submitted,  approved)  . 

(2)  Record  and  report  information  needed  to  manage  the  data  files  effectively,  including  the  status  of 
updated  versions  of  files. 

Configuration  Management  Plan  (CMP).  The  document  defining  how  configuration  management  will  be 
implemented  (including  policies  and  procedures)  for  a  particular  acquisition  or  program. 

Configuration  Status  Accounting  (CSA) .  The  recording  and  reporting  of  information  needed  to  manage 
configuration  items  effectively,  including: 

•  A  record  of  the  approved  configuration  documentation  identification  numbers. 

•  The  status  of  proposed  changes,  and  deviations,  to  the  configuration. 

•  The  implementation  status  of  approved  changes. 

•  The  configuration  of  all  units  of  the  configuration  item  in  the  operational  inventory. 

Contractor.  An  individual,  partnership,  company,  corporation,  association  or  other  service,  having  a  contract 
with  for  the  design,  development,  manufacture,  maintenance,  modification,  or  supply  of  items  under  the  terms 
of  a  government  contract. 

Data.  Recorded  information,  regardless  of  medium  or  characteristics,  of  any  nature,  including  administrative, 
managerial,  financial,  and  technical. 

Database.  A  collection  of  related  data  stored  in  one  or  more  computerized  files  in  a  manner  that  can  be  accessed 
by  users  or  computer  programs  via  a  database  management  system. 

Defect.  Any  nonconformance  of  a  characteristic  with  specified  requirements. 

Deficiencies.  Deficiencies  consist  of  two  types: 

•  Conditions  or  characteristics  in  any  item  which  are  not  in  accordance  with  the  item’s  current  approved 
configuration  documentation;  or 

•  Inadequate  (or  erroneous)  item  configuration  documentation  which  has  resulted,  or  may  result,  in  units 
of  the  item  that  do  not  meet  the  valid  requirements  for  the  item. 

Design  change.  See  “engineering  change”. 

Developmental  configuration.  The  contractor’s  design  and  associated  technical  documentation  that  defines  the 
evolving  configuration  of  a  configuration  item  during  development.  It  is  under  the  developing  contractor’s 
configuration  control  and  describes  the  design  definition  and  implementation.  The  developmental  configuration 
for  a  configuration  item  consists  of  the  contractor’s  released  hardware  and  software  designs  and  associated 
technical  documentation  until  establishment  of  the  formal  product  baseline. 

Deviation.  A  specific  written  authorization,  to  depart  from  a  particular  requirement(s)  of  an  item’s  current 
approved  configuration  documentation  for  a  specific  number  of  units  or  a  specified  period  of  time,  or  which 
during  or  after  manufacture,  having  been  submitted  for  Government  inspection  or  acceptance,  is  found  to  depart 
from  specified  requirements,  but  nevertheless  is  considered  suitable  for  use  “as  is”.  (A  deviation  differs  from  an 
engineering  change  in  that  an  approved  engineering  change  requires  corresponding  revision  of  the  items  current 
approved  configuration  documentation,  where  as  a  deviation  does  not.  However,  it  shall  be  required  that  a 
unique  identity  be  given  to  deviated  end  items  and  thereafter  that  status  accounting  records  reflect  usage  of  that 
unique  identity,  hence  deviated  parts/materials.) 
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Engineering  change.  A  change  to  the  current  approved  configuration  documentation  of  a  configuration  item  at 
any  point  in  the  life  cycle  of  the  item. 

Engineering  change  justification  code.  A  code  which  indicates  the  reason  for  a  Class  I  engineering  change. 

Engineering  change  priorities.  The  priority  (emergency,  urgent,  routine)  assigned  to  a  Class  I  engineering 
change  which  determines  the  relative  speed  at  which  the  Engineering  Change  Proposal  is  to  be  reviewed, 
evaluated,  and,  if  approved,  ordered  and  implemented. 

Engineering  Change  Proposal  (ECP).  A  proposed  engineering  change  and  the  documentation  by  which  the 
change  is  described,  justified,  and  submitted  to  the  Government  for  approval  or  disapproval. 

Engineering  Change  Proposal  Types.  A  term  covering  the  subdivision  of  Class  I  Engineering  Change  Proposals 
on  the  basis  of  the  completeness  of  the  available  information  delineating  and  defining  the  engineering  change. 
They  will  be  identified  as  preliminary  or  formal. 

Engineering  release.  An  action  whereby  configuration  documentation  or  an  item  is  officially  made  available  for 
its  intended  use. 

Engineering  Release  Record  (ERR).  A  record  used  to  release  configuration  documentation. 

Evaluation.  The  process  of  determining  whether  an  item  or  activity  meets  specified  criteria. 

Exchangeability  of  items  .  See  Interchangeable  .item,  Replacement  Item,  and  Substitute  item. 

Firmware.  The  combination  of  a  hardware  device  and  computer  instructions  and/or  computer  data  that  reside  as 
read  only  software  on  the  hardware  device.  The  software  portion  of  firmware  is  considered  software  and  is 
subject  to  all  of  the  software  configuration  management  requirements  in  this  standard.  The  firmware  itself  (i.e. 
the  hardware  device  after  the  software  has  been  permanently  stored  (i.e.  burned  in)  is  considered  hardware  and 
is  subject  to  all  of  the  hardware  configuration  management  requirements  in  this  standard  in  addition  to 
requirements  that  apply  specifically  to  firmware. 

Fit.  The  ability  of  an  item  to  physically  interface  or  interconnect  with  or  become  an  integral  part  of  another 
item. 

Form.  The  shape,  size,  dimension,  mass,  weight,  and  other  visual  parameters  which  uniquely  characterize  an 
item.  For  software,  firmware  form  denotes  the  language  and  media. 

Function.  The  action  or  actions  which  an  item  is  designed  to  perform. 

Functional  area.  A  distinct  group  of  system  performance  requirements  which,  together  with  all  other  such 
groupings,  forms  the  next  lower-level  breakdown  of  the  system  on  the  basis  of  function. 

Functional  (Build-To)  Baseline  (FBL).  The  approved  functional  configuration  documentation. 

Functional  characteristics.  Quantitative  performance  parameters  and  design  constraints,  including  operational 
and  logistic  parameters  and  their  respective  tolerances.  Functional  characteristics  include  all  performance 
parameters,  such  as  range,  speed,  lethality,  reliability,  maintainability,  responsiveness,  timeliness,  and  safety. 

Functional  configuration  Audit  (FCA).  The  formal  examination  of  functional  characteristics  of  a  configuration 
item,  prior  to  acceptance,  to  verify  that  the  item  has  achieved  the  requirements  specified  in  its  functional  and 
allocated  configuration  documentation. 

Functional  configuration  Documentation  (FCD).  The  documentation  describing  the  system’s  functional, 
performance,  interoperability,  and  interface  requirements  and  the  verifications  required  to  demonstrate  the 
achievement  of  those  specified  requirements. 


Hardware.  Items  made  of  materiel,  such  as  weapons,  aircraft,  ships,  tools,  computers,  vehicles,  and  their 
components  (mechanical,  electrical,  electronic,  hydraulic,  pneumatic). 

Hardware  Configuration  Item  (HWCI).  An  aggregation  of  hardware  that  satisfies  an  end  use  function  and  is 
designated  for  purposes  of  specification,  interfacing,  qualification  testing,  configuration  management,  or  other 
purposes.  A  hardware  configuration  item  (HWCI)  may  also  be  interchangeably  defined  as  hardware  item  (HI). 

Hardware  Item  (HI).  See  Hardware  Configuration  Item. 

Integrated  Logistics  Support  (ILS).  A  disciplined  approach  to  the  activities  necessary  to: 

•  cause  support  considerations  to  be  integrated  into  system  and  equipment  design, 

•  develop  support  requirements  that  are  consistently  related  to  design  and  to  each  other, 

•  acquire  the  required  support,  and 

•  provide  the  required  support  during  the  operational  phase  at  minimum  cost.  (Source:  MIL-STD-1388- 

1) 

Interchangeable  item.  One  which  possesses  such  physical  characteristics  as  to  be  equivalent  in  reliability,  and 
maintainability,  to  another  item  of  identical  purposes,  is  capable  of  being  exchanged  for  the  other  item,  without 
selection  for  fit  or  performance  without  alteration  of  the  items  themselves  or  adjoining  items,  except  for 
adjustments.  (Source:  MIL-STD-280) 

Interface.  The  functional  and  physical  characteristics  required  to  exist  at  a  common  boundary. 

Interface  control.  The  process  of  identifying,  documenting  and  controlling  all  functional  and  physical 
characteristics  relevant  to  the  interfacing  of  two  or  more  items  provided  by  one  or  more  organizations. 

Interface  Control  Documentation  (ICD).  Interface  control  drawings,  requirements,  or  other  documentation 
which  depicts  physical  and  functional  interface  of  related  or  co-functioning  items. 

Interface  Control  Working  Group  (ICWG).  For  programs  which  encompass  a  system,  configuration  item,  or  a 
computer  software  configuration  item  design  cycle,  an  ICWG  is  established  to  control  interface  activity  among 
the  Government,  contractors,  or  other  agencies,  including  resolution  of  interface  problems  and  documentation 
of  interface  agreements. 

Interoperability.  The  ability  of  the  defense  services  and  agencies  to  exchange  information  with  each  other  (joint 
operations)  or  with  an  allied  system  (combined  operations)  to  enable  them  to  operate  effectively  together. 

Item.  A  non-specific  term  used  to  denote  any  product,  including  systems,  materials,  parts,  subassemblies,  sets 
accessories  etc.  (Source:  MIL-STD-280) 

Life  Cycle.  A  generic  term  covering  all  phases  of  acquisition  operation,  and  logistics  support  of  an  item, 
beginning  with  concept  definition  and  continuing  through  disposal  of  the  item. 

Life  cycle  cost .  The  total  cost  to  the  Government  of  acquisition  and  ownership  of  that  system  over  its  life  cycle. 
It  includes  the  cost  of  development,  acquisition,  support,  and  where  applicable  disposal. 

Manufacturer’s  code.  See  “Commercial  and  Government  Entity  (CAGE)  code” 

Material.  A  generic  term  covering  systems,  equipment,  stores,  supplies,  and  spares,  including  related 
documentation,  manuals,  computer  hardware,  firmware  and  software. 

Non-conformance.  The  failure  of  a  unit  or  product  to  conform  to  specified  requirements. 

N on-developmental  Item  (NDI).  Non-developmental  item  is  a  broad  generic  term  that  covers  material  available 
from  a  wide  variety  of  sources  with  little  or  no  development  effort  required  by  the  Government.  NDIs  include: 
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•  Items  obtained  from  a  domestic  or  foreign  commercial  marketplace. 

•  Items  already  developed  and  in  use  by  other  services,  Defense  activities,  and  Government  agencies. 

•  Items  already  developed  by  foreign  governments  which  can  be  supplied  in  accordance  with  mutual 
defense  cooperation  agreements  and  Federal  and  DoD  acquisition  regulations. (SD-2) 

Non-recurring  Costs.  As  applied  to  ECPs,  these  are  one  time  costs,  which  will  be  incurred  if  an  engineering 
change  is  approved  and  which  are  independent  of  the  quantity  of  items  changed,  such  as  cost  of  redesign, 
special  tooling,  or  testing. 

Notice  of  Revision  (NOR).  A  document  used  to  define  revisions  to  drawings,  associated  lists,  or  other 
referenced  documents  which  require  revision  after  Engineering  Change  Proposal  approval. 

Original.  The  current  design  activity  document  or  digital  data  file(s)  of  record. 

Physical  characteristics.  Quantitative  and  qualitative  expressions  of  material  features,  such  as  composition, 
dimensions,  finishes,  form,  fit,  and  their  respective  tolerances. 

Physical  configuration  Audit  (PCA).  The  formal  examination  of  the  “as-built”  configuration  of  a  configuration 
item  against  its  technical  documentation  to  establish  or  verify  the  configuration  item’s  product  baseline. 

Product  (As-Built)  Baseline  (PBL).  The  approved  product  configuration  documentation.  In  addition  to  this 
documentation,  the  product  baseline  of  a  configuration  item  may  include  the  actual  hardware  equipment, 
computer  software  and  firmware. 

Product  Configuration  Documentation  (PCD).  The  combined  performance/design  documentation  utilized  for 
the  production/procurement  of  the  CL  The  PCD  incorporates  the  ACD  describing  a  Cl’S  functional, 
performance,  interoperability  and  interface  requirements  and  the  verifications  required  to  confirm  the 
achievement  of  those  specified  requirements.  The  PCD  also  includes  such  additional  design  documentation, 
ranging  from  the  form  and  fit  information  about  the  proven  design  to  a  compete  design  disclosure  package,  as  is 
deemed  necessary  for  the  acquisition  program. 

Recurring  cost.  Costs  which  are  incurred  for  each  item  changed  or  for  each  service  or  document  ordered. 

Release.  The  designation  by  the  contractor  that  a  document  is  complete  and  suitable  for  use.  Release  means  that 
the  document  is  subject  to  the  contractor’s  configuration  control  procedures. 

Repair.  A  procedure  which  reduces  but  not  completely  eliminates  a  nonconformance  and  which  has  been 
reviewed  and  concurred  in  by  the  MRB  and  approved  for  use  by  the  Government.  The  purpose  of  repair  is  to 
reduce  the  effect  of  the  nonconformance.  Repair  is  distinguished  from  rework  in  that  the  characteristic  after 
repair  still  does  not  completely  conform  to  the  applicable  drawings,  specifications,  or  contract  requirements. 
Proposed  repairs  approved  by  the  Government  are  authorized  for  ’’use  on  a  one-time  basis  only.  (Source:  MIL- 
STD-1520) 

Replacement  item.  One  which  is  interchangeable  with  another  item,  but  which  differs  physically  from  the 
original  item  in  that  the  installation  of  the  replacement  item  requires  operations  such  as  drilling,  reaming, 
cutting,  filing,  shimming,  etc.  in  addition  to  the  normal  application  and  methods  of  attachment.  (Source:  MIL- 
STD-280) 

Retrofit .  The  incorporation  of  new  design  parts,  software,  or  firmware  resulting  from  an  approved  engineering 
change  to  an  item’s  current  approved  configuration  documentation  into  already  Government  accepted  (DD-250) 
and/or  operational  items. 

Rework.  A  procedure  applied  to  a  nonconformance  that  will  completely  eliminate  it  and  result  in  a 
characteristic  that  conforms  completely  to  the  drawings,  specifications,  or  contract  requirements  .  (Source: 
MIL-STD-1520) 
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Software.  Computer  programs,  procedures  and  data  pertaining  to  the  operation  of  a  computer  system.  Data  may 
include,  for  example,  information  in  databases,  rule  bases,  and  configuration  data.  Procedures  may  include,  for 
example,  interpreted  scripts.  Although  some  definitions  of  software  include  documentation,  this  standard  limits 
the  definition  to  computer  programs,  procedures,  and  data.  [Definition  adapted  from  IEEE  Standard  Glossary 
of  Software  Engineering  Terminology.  IEEE  Std  610.12  dated  September  28,1990.]  The  definition  of 
software  is  independent  of  the  media  on  which  the  software  is  stored  or  the  device  in  which  the  software 
executes.  Thus,  the  software  portion  of  firmware  is  considered  software  and  is  subject  to  all  of  the  software 
configuration  management  requirements  defined  in  this  standard. 

Software  Item  (SI).  See  Computer  Software  Configuration  Item. 

Software  unit.  An  element  in  the  design  of  a  software  item;  for  example,  a  major  subdivision,  a  class,  object, 
module,  function,  routine,  or  database.  Software  units  may  occur  at  different  levels  of  a  hierarchy  and  may 
consist  of  other  software  units.  Software  units  in  the  design  may  or  may  not  have  a  one-to-one  relationship  with 
the  code  and  data  entities  (routines,  procedures,  databases,  data  fules,  etc.)  that  implement  them  or  with  the 
computer  files  containing  those  entities.  A  software  unit  is  sometimes  called  a  computer  software  unit  (CSU). 

Specification.  A  document  prepared  specifically  to  support  acquisition  which  clearly  and  accurately  describes 
essential  technical  requirements  for  purchasing  materiel.  Procedures  necessary  to  determine  that  the 
requirements  for  the  materiel  covered  by  the  specification  have  been  met  are  also  included.  (Source:  MIL-STD- 
961) 

Specification  Change  Notice.  A  document  used  to  propose,  transmit,  and  record  changes  to  a  specification. 

Substitute  item.  One  which  possesses  such  functional  and  physical  characteristics  as  to  be  capable  of  being 
exchanged  for  another  only  under  specified  conditions  or  in  particular  applications  and  without  alteration  of  the 
items  themselves  or  of  adjoining  items.  (Source:  MIL-STD-280) 

Support  equipment.  Equipment  and  computer  software  required  to  maintain,  test,  or  operate  an  item  or  facility 
in  its  intended  environment. 

Survivability.  The  capability  of  a  system  to  avoid  or  withstand  a  hostile  environment  without  suffering  an 
abortive  impairment  of  its  ability  to  accomplish  its  designated  mission. 

System.  A  composite  of  equipment,  software,  firmware,  people  and  processes  capable  of  performing  and/or 
supporting  an  operational  role.  A  complete  system  includes  all  equipment,  related  facilities,  material,  software, 
services  and  personnel  required  for  its  operation  and  support  to  the  degree  that  it  can  be  considered  a  self- 
sufficient  unit  in  its  intended  operational  environment. 

Technical  data.  Technical  data  is  recorded  information  (regardless  of  the  form  or  method  of  recording)  of  a 
scientific  or  technical  nature  (including  computer  software  documentation)  relating  to  supplies  procured  by  an 
agency.  Technical  data  does  not  include  computer  software  or  financial,  administrative,  cost  or  pricing,  or 
management  data  or  other  information  incidental  to  contract  administration. 

•  Technical  data  is  required  to  define  and  document  an  engineering  design  or  product  configuration 
(sufficient  to  allow  duplication  of  the  original  items)  and  is  used  to  support  production,  engineering, 
and  logistics  activities. 

•  A  technical  data  package  should  include  all  engineering  drawings,  associated  lists,  process 
descriptions,  and  other  documents  which  define  the  physical  geometry,  material  composition, 
performance  characteristics,  manufacture,  assembly,  and  acceptance  test  procedures.  For  software, 
technical  data  should  include  architectural  and  design  products. 

•  Technical  data  which  provides  instructions  for  the  installation,  operation,  maintenance,  training,  and 
support  of  a  system  or  equipment  can  be  formatted  into  a  technical  manual. 

A  technical  manual  normally  includes  operation  and  maintenance  instructions,  parts  lists  or  parts  breakdown, 
and  related  technical  information  or  procedures  exclusive  of  administrative  procedures.  This  data  may  be 
presented  in  any  form  (e.g.,  hard  copy,  audio  and  visual  displays,  magnetic  tape  disks,  or  other  electronic 


11 


devices).  Technical  orders  that  meet  the  criteria  of  this  definition  may  also  be  classified  as  technical  manuals. 
(Title  10,  United  States  Code,  Section  2302, ’’Definitions”) 

Technical  data  Package.  See  “Technical  data”. 

Technical  documentation.  See  “Technical  data”. 

Technical  reviews.  A  series  of  system  engineering  activities  by  which  the  technical  progress  on  a  project  is 
assessed  relative  to  its  technical  or  contractual  requirements.  The  reviews  are  conducted  at  logical  transition 
points  .in  the  development  effort  to  identify  and  correct  problems  resulting  from  the  work  completed  thus  far 
before  the  problems  can  disrupt  or  delay  the  technical  progress.  The  reviews  provide  a  method  for  the  contractor 
and  Government  to  determine  that  the  development  of  a  configuration  item  and  its  documentation  have  met 
contract  requirements. 

Training  equipment.  All  types  of  maintenance  and  operator  training  hardware,  devices,  audio-visual  training 
aids,  and  related  software  which: 

•  Are  used  to  train  maintenance  and  operator  personnel  by  depicting,  simulating,  or  portraying  the 
operational  or  maintenance  characteristics  of  an  item  or  facility. 

•  Are  kept  consistent  in  design,  construction,  and  configuration  with  such  items  in  order  to  provide 
required  training  capability. 

Unit.  An  assembly  or  any  combination  of  parts,  subassemblies  and  assemblies  mounted  together,  normally 
capable  of  independent  operation  in  a  variety  of  situations.  (Examples:  Hydraulic  jack,  electric  motor,  electronic 
power  supply,  internal  combustion  engine,  electric  generator,  radio  receiver.)  This  term  replaces  the  term 
“component.”  A  unit  should  not  be  confused  with  a  software  unit.  Note.  The  size  of  an  item  is  a  consideration 
in  some  cases.  An  electric  motor  for  a  clock  may  be  considered  as  a  part  in  as  much  as  it  is  not  normally  subject 
to  disassembly.  (Source:  MIL-STD-280) 

Version.  An  identified  and  documented  body  of  software.  Modifications  to  a  version  of  software  (resulting  in  a 
new  version)  require  configuration  management  actions  by  either  the  Contractor,  the  Government,  or  both. 

Work  Breakdown  Structure  (WBS).  A  work  breakdown  structure  (WBS)  is  a  product-oriented  family  tree 
composed  of  hardware,  software,  services,  data  and  facilities  which  results  from  systems  engineering  efforts 
during  the  acquisition  of  a  defense  materiel  item.  A  work  breakdown  structure  displays  and  defines  the 
product(s)  to  be  developed  and/or  produced  and  relates  the  elements  of  work  to  be  accomplished  to  each  other 
and  to  the  end  product(s).  (Source:  MIL-STD-881) 

Work  breakdown  structure  element.  A  work  breakdown  structure  element  is  a  discrete  portion  of  a  work 
breakdown  structure.  A  work  breakdown  structure  element  may  bean  identifiable  item  of  hardware,  software, 
services,  data  or  facilities.  (Source:  MIL-STD-881) 
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4.0 


GENERAL  REQUIREMENTS 


4.1  Basic  requirements. 

The  contractor  shall  implement  an  internal  configuration  management  system  for  the  control  of  all  configuration 
documentation,  physical  media,  and  physical  parts  representing  or  comprising  the  product.  For 
software/firmware,  the  system  shall  address  the  evolving  developmental  configuration  and  support 
environments  (engineering,  implementation  and  test)  used  to  generate  and  test  the  product.  The  contractor’s 
configuration  management  system  shall  consist  of  the  following  elements: 

•  Configuration  identification. 

•  Configuration  control. 

•  Configuration  status  accounting. 

•  Configuration  audits. 

Contractors  shall  implement  the  requirements  of  this  TOR  as  identified  in  the  contract  statement  of  work 
(SOW)  and  insure  compliance  to  the  requirements  by  subcontractors. 

4.2  Planning. 

The  contractor  shall  plan  a  configuration  management  program  in  accordance  with  the  requirements  of  this 
standard,  tailored  appropriately  for  the  particular  CI(s) ,  their  scope  and  complexity,  and  the  contracted  phase(s) 
of  the  life  cycle.  Planning  shall  be  consistent  with  the  objectives  of  a  continuous  improvement  program  which 
includes  the  analysis  of  identified  problem  areas  and  correction  of  procedures  as  necessary  to  prevent 
reoccurrence.  The  contractor’s  configuration  management  planning  shall  include: 

•  The  objectives  of  the  configuration  management  program  and  of  each  applicable  configuration 
management  element 

•  The  configuration  management  organization  and  organizational  relationships 

•  Responsibilities  and  authority  of  configuration  management  managers 

•  Configuration  management  resources  (tools,  techniques,  and  methodologies) 

•  Coordination  with  internal  and  external  agencies  (e.g.,  program  managers,  other  contractors,  other 
Government  agencies,  CCBs,  foreign  governments) 

•  Configuration  management  policies,  processes,  procedures,  methods,  records,  reports  and  forms;  and 

•  Computer-aided  Acquisition  and  Logistics  Support  (CALS)  configuration  management  in  accordance 
with  paragraph  4.3. 

4.3  Computer-aided  Acquisition  and  Logistic  Support  (CALS) 

Configuration  documentation  shall  be  provided  in  either  hard  copy  data  transfer,  transfer  of  processable  data 
files,  interactive  access  to  data  through  contractor  integrated  technical  information  services,  or  combination  of 
the  above,  as  specified  in  the  contract.  The  contractor’s  planning  shall  address  all  configuration  management 
technical  data  requirements  of  the  contract  as  far  as  data  handling,  processing,  storage,  integrity,  transfer, 
security,  and  maintenance  are  concerned,  over  the  performance  period  of  the  contract.  The  contractor  shall 
propose  to  the  Government,  as  applicable  and  in  accordance  with  the  changes  clause  of  the  contract,  any 
requirements  that  may  be  imposed  on  the  Government  that  will  require  associated  contractor  effort  to  maintain 
the  security  and  integrity  of  shared  data. 

4.3.1  Data  distribution/access 

The  contractor  shall  affix  distribution  statements  to  technical-data  in  accordance  with  the  contract.  Access  to 
data  shall  be  limited  in  accordance  with  the  applicable  distribution  statements,  as  well  as  by  data  rights, 

Contract  Data  Requirements  List  (CDRL)  distribution,  security  requirements,  and  data  status  level  (released, 
submitted  or  approved  unless  otherwise  specified).  (See  6.6) 

4.3.2  Automated  processing  and  submittal  of  data. 

To  facilitate  processing  of  submitted  data,  the  contractor  shall  use  automated  processing  and  electronic 
submittal  techniques,  when  specified  in  the  contract.  Where  the  data  requirement  is  for  data  that  is  illustrated, 
for  reference  purposes,  herein  on  a  DD  Form  (e.g.,  DD  Form  1692  for  an  ECP  ),  the  contractor  may  sequentially 
address  the  essential  and  applicable  data  elements  of  the  submitted  data  by  block  number  and  title,  or  may 
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provide  the  data  on  an  electronic  version  of  the  form  as  desired.  Textual  data  in  electronic  form  shall  be  by 
paragraph  number,  or  topic  heading,  as  applicable,  in  accordance  with  the  format  and  content  requirements  for 
the  data  specified  in  the  contract. 

•  The  contractor  shall  make  technical  data  available  to  the  government,  as  required  by  contract. 

•  The  contractor  shall  maintain  the  current  status  (working,  released,  submitted,  approved)  of  all  digital 
technical  data  in  the  data  base  at  all  times.  Any  data  electronically  transferred  by  the  contractor  to  the 
Government  shall  be  so  identified. 

•  The  contractor  shall  implement  procedures  to  identify  and  control  data  during  the  contractor  and 
Government  review  and  update  cycle.  As  a  minimum,  these  procedures  shall  address: 

-  Identification  of  data  files  submitted  to  the  Government  for  review,  annotation,  comment  and 
approval/disapproval,  as  applicable  in  accordance  with  Government  specified  review  and  approval 
requirements.  Each  submitted  digital  data  file  shall  have  a  unique  identifier  (e.g.,  file  name)which 
shall  indicate  file  version,  and  “submitted”  status.  To  assure  file  integrity,  the  file  naming 
convention  shall  distinguish  an  altered  (annotated,  redlined)  file  version  from  the  originally 
submitted  file  version  by  renaming  it  as  a  separate  working  status  file. 

-  How  data  and  changes  are  transmitted. 

-  How  changes  from  previous  versions  are  indicated. 

-  Notification/acknowledgement  of  receipt,  return,  or  acceptance. 

Indication  of  time  constraints,  if  any,  for  automatic  data  acceptance;  and 

-  Data  status  accounting. 

4.3.3  Interactive  access  to  digital  data. 

In  addition  to  the  above  requirements,  the  contractor’s  integrated  technical  information  service  shall,  where 
contractually  specified,  accommodate  pre-defined  query  and  extraction  of  data  and  shall  implement  procedures 
that  define  the  control  of  data  bases  and  files  during  the  Government’s  and  contractor’s  interactive  review  and 
update  cycles.  As  a  minimum,  the  following  shall  be  defined: 

•  How  data  is  to  be  accessed; 

•  Request  for  access  and  logging  of  access  for  read-only  or  annotation; 

•  Naming  of  temporary  working  version  of  the  file(s)  For  purpose  of  annotation/mark  up; 

•  Means  of  indicating  whether  a  comment/annotation  is 

•  essential/suggested; 

•  Re-identification  of  marked  up  versions,  as  required; 

•  Method  of  indicating  acceptance,  provisional  acceptance,  approval,  or  rejection,  as  applicable; 

•  Time  constraints,  if  any,  on  data  acceptance  (e.g.  automatic  approval)  by  any  links  in  the  contractor’s 
or  the  Government’s  review  and  approval  chains; 

•  Automated  status  accounting,  including  tracking  of  disposition  of  required  changes;  and 

•  Re-identification  of  changed  files. 

4.4  Configuration  identification. 

The  contractor’s  process  for  configuration  identification  shall  include  the  selection  of  CIs;  the  determination  of 
the  types  of  configuration  documentation  required  for  each  Cl;  and  the  issuance  of  numbers  and  other  identifiers 
affixed  to  the  CIs  and  to  the  technical  documentation  that  comprises  the  Cl’s  configuration  documentation. 

4.5  Configuration  control 

The  contractor  shall  apply  internal  configuration  control  measures  to  the  configuration  documentation  for  each 
Cl,  prior  to  the  time  that  it  is  baseline  by  the  Government.  The  contractor  shall  apply  configuration  control 
measures  to  each  baselined  configuration  item,  and  its  configuration  documentation,  in  accordance  with  this 
standard.  The  configuration  control  program  shall: 

•  Ensure  effective  control  of  all  CIs  and  their  approved  configuration  documentation. 

•  Provide  effective  means,  as  applicable,  for  proposing  engineering  changes  to  CIs,  requesting 
deviations  pertaining  to  such  items,  preparing  Notices  of  Revision,  and  preparing  Specification  Change 
Notices. 

•  Ensure  implementation  of  approved  changes. 
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4.6  Configuration  Status  Accounting  [CSA]. 

The  contractor  shall  implement  a  CSA  system.  The  CSA  system  shall: 

•  Identify  the  current  approved  configuration  documentation  and  identification  number  associated  with 
each  CL 

•  Record  and  report  the  status  of  proposed  engineering  changes  from  initiation  to  final 
approval/contractual  implementation. 

•  Record  and  report  the  results  of  configuration  audits  to  include  the  status  and  final  disposition  of 
identified  discrepancies. 

•  Record  and  report  the  status  of  all  critical  and  major  requests  for  deviations  which  affect  the 
configuration  of  a  CL 

•  Record  and  report  implementation  status  of  authorized  changes. 

•  Provide  the  traceability  of  all  changes  from  the  original  baselined  configuration  documentation  of  each 
Cl . 

•  Identify  dependencies  among  CIs. 

•  Report  the  effectively  and  installation  status  of  configuration  changes  to  all  CIs  at  all  locations. 

4.7  Configuration  audits. 

Configuration  audits  shall  be  performed  before  establishing  a  product  baseline  for  the  item.  Configuration 
audits  consist  of  the  Functional  Configuration  Audit  (FCA)  and  the  Physical  Configuration  Audit  (PCA). 

Additional  PC  As  may  be  performed  during  production  for  selected  changes  to  the  item’s  configuration 
documentation  or  when  contractors  are  changed.  In  accordance  with  the  terms  of  the  contract,  the  contractor 
tasked  with  the  development  or  production  of  the  item  shall: 

•  Support  the  conduct  of  the  FCA/PCA. 

•  Participate  in  the  resolution  of  discrepancies  identified  during  the  conduct  of  the  FCA/PCA. 
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5.0 


DETAILED  REQUIREMENTS 


5.1  Purpose. 

The  purpose  of  this  section  is  to  identify  detailed  requirements  that  should  be  selectively  applied  to  a 
configuration  management  program. 

5.2  Configuration  management  administration. 

5.2.1  Contractor’s  CM  Plan. 

If  a  CM  Plan  is  identified  as  a  requirement  in  the  contract  DD  Form  1423,  the  Contractor’s  Configuration 
Management  Plan  shall  be  in  accordance  with  the  requirements  of  the  contract  and  shall  describe  the  processes, 
methods,  and  procedures  to  used  to  manage  the  functional  and  physical  characteristics  of  the  assigned  CI(s).  If 
so  identified,  the  contractor  shall: 

•  Develop  a  Configuration  Management  Plan  in  accordance  with  the  requirements  of  DI-CMAN- 
80858B; 

•  Submit  the  plan  and  changes  thereto  in  accordance  with  the  CDRL;  and 

•  Implement  the  activities  required  by  this  standard  in  accordance  with  the  approved  plan. 

5.2.2  Work  Breakdown  Structure  (WBS). 

The  contractor  shall  ensure  traceability  of  CIs  to  the  WBS  elements  when  a  WBS  is  invoked  the  contract. 

5.2.3  Technical  reviews. 

The  contractor  shall  ensure  that  the  configuration  management  representatives  participate  in  all  technical 
reviews  conducted  in  accordance  with  the  contract  requirements.  The  role  of  configuration  management  in  the 
technical  review  process  shall  include  evaluating  the  adequacy  of  the  type  and  content  of  the  configuration 
documentation,  ascertaining  that  the  configuration  documentation  is  under  formal  Government  and/or  internal 
configuration  control,  and  determining  whether  problems/action  items  identified  at  the  review  will  require 
submittal  of  Engineering  Change  Proposals  against  the  current  approved  configuration  documentation. 

5.3  Configuration  identification. 

5.3.1  Purpose  of  configuration  identification. 

The  purpose  of  configuration  identification  shall  be  to  incrementally  establish  and  maintain  a  definitive  basis 
for  control  and  status  accounting  for  a  Cl  throughout  its  life  cycle.  To  accomplish  configuration  identification, 
the  contractor  shall  for  hardware,  software  and  firmware: 

•  Select  CIs; 

•  Select  configuration  documentation  to  be  used  to  define  configuration  baselines  for  each  Cl; 

•  Establish  a  release  system  for  configuration  documentation; 

•  Define  and  document  interfaces; 

•  Enter  each  item  of  configuration  documentation  and  computer  software  source  code  into  a  controlled 
developmental  configuration; 

•  Establish  the  functional,  allocated,  and  product  baselines  at  the  appropriate  points  in  the  system/Cl  life 
cycle,  upon  Government  approval/contractual  implementation  of  the  applicable  configuration 
documentation,  and  in  accordance  with  contract  requirements; 

•  Assign  identifiers  to  CIs  and  their  component  parts  and  associated  configuration  documentation, 
including  revision  and/or  version  numbers  where  appropriate.  Assigning  serial  and  lot  numbers,  as 
necessary,  to  establish  the  Cl  effectivity  of  each  configuration  of  each  item  of  hardware,  software  and 
firmware; 

•  Ensure  that  the  marking  or  labeling  of  items  and  documentation  with  their  applicable  identifiers 
enables  correlation  between  the  item,  configuration  documentation,  and  other  associated  data;  and 

•  Ensure  that  applicable  identifiers  are  embedded  in  the  source  code,  and  where  contractually  specified, 
electronically  embedded  in  alterable  microprocessors  (firmware). 
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5.3.2  Configuration  Item  selection. 

The  contractor  shall  select  and  recommend  potential  Cl’s  to  the  Government.  Any  item  requiring  logistics 
support  and  designated  for  separate  procurement  is  a  CL  However,  all  Cl’s  associated  with  any  given 
development  program  are  not  necessarily  designated  as  Cl’s  at  the  same  point  in  time.  Computer  hardware, 
including  the  hardware  portion  of  firmware,  will  be  treated  as  CIs.  Computer  software  will  be  treated  as  CSCIs 
throughout  the  life  of  the  program  regardless  of  how  the  software  will  be  stored.  The  contractor  is,  however, 
required  to  maintain  data  regarding  CI/CSCI  dependencies.  The  final  Cl  selection  will  be  made  by  the 
Government.  (See  6.3) 

5.3.3  Developmental  configuration. 

The  contractor  shall  establish  and  implement  a  developmental  configuration  management  process  for  hardware, 
software  and  firmware.  This  process  shall  be  used  to  control  the  documentation  and  repositories  containing  the 
elements  of  the  developmental  configuration.  The  contractor  shall  prepare  a  problem/change  report  to  describe 
and  prioritize  each  problem  detected  in  hardware,  software  and  firmware  or  the  documentation  that  has  been 
placed  under  internal  configuration  control.  The  problem/change  report  shall  describe  the  corrective  action 
needed  and  the  actions  taken  to  resolve  the  problem.  These  reports  shall  serve  as  input  to  the  corrective  action 
process.  The  contractor  shall  implement  a  corrective  action  process  for  handling  all  problems  detected  in  the 
products  under  internal  configuration  management  control.  The  corrective  action  process  shall  ensure  that  all 
detected  problems  are  promptly  reported,  action  is  initiated  on  them,  resolution  is  achieved,  status  is  tracked  and 
reported,  and  records  of  the  problems  are  maintained  for  the  life  of  the  contract. 

5.3.3. 1  Documentation  library. 

The  contractor  shall  establish  a  documentation  library  and  implement  procedures  for  controlling  the  documents 
residing  within  the  documentation  library. 

5.3.3.2  Drawing  library. 

The  contractor  shall  establish  a  drawing  library  and  implement  procedures  for  controlling  the  drawings, 
computer  aided  design  (CAD),  and  computer  aided  manufacturing  (CAM)  instructions  residing  within  the 
drawing  library. 

5.3.3.3  Software  Development  Library. 

The  contractor  shall  establish  a  software  development  library  (SDL)  and  implement  procedures  for  controlling 
the  software  residing  within  the  SDL. 

5.3.4  Configuration  baselines. 

Configuration  management  normally  employs  three  types  of  configuration  baselines,  the  functional,  allocated, 
and  product  baselines,  to  provide  for  the  progressive  definition  and  documentation  of  the  requirements  and 
design  information  describing  the  various  CIs  designated  for  a  system.  The  contractor  shall  recommend  to  the 
Government  the  types  of  specifications  and  associated  documentation  to  a  level  of  detail  commensurate  with 
logistic  support  requirements  and  procurement  strategies  that  should  be  used  to  define  each  Cl;  however,  the 
actual  specifications  provided  shall  be  those  ultimately  ordered  in  the  contract.  Those  specifications  are  subject 
to  review  and  approval/contractual  implementation  by  the  Government.  The  appropriate  baseline  for  each  Cl 
shall  be  established  with  the  approval/contractual  implementation  of  that  specification  as  defined  in  the 
contract.  (See  6.3) 

5.3.4. 1  Configuration  baselines  and  their  configuration  documentation. 

The  contractor  shall  generate  the  configuration  documentation  required  for  the  configuration  baselines  being 
established  by  the  Government.  The  FCD,  ACD,  and  PCD  defining  the  configuration  baselines  shall  be 
mutually  consistent  and  compatible.  Each  succeeding  level  of  configuration  documentation  from  FCD  to  ACD 
to  PCD  shall  be  traceable  to,  and  be  a  detailed  extension  of,  its  predecessor  (s).  If  a  conflict  arises  between 
levels  of  documentation,  the  order  of  precedence  shall  be  (1)  FCD,  (2)  ACD,  and  (3)  PCD. 
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5.3.4. 1.1  Functional  configuration  Documentation  (FCD) 

The  contractor  shall  generate  the  documentation  required  for  the  functional  baseline  as  specified  in  the  contract 
DD  Form  1423.  The  FCD  shall  be  in  the  form  of  a  system  specification  for  a  system,  plus  other  applicable 
documentation  (for  example.  Interface  Requirements  Specifications  and  Interface  Control  Documents  for  the 
system).  (For  Programs  or  contracts  involving  the  development  of  a  single  Cl,  a  system  specification  should  not 
be  generated.  )  The  FCD  shall  also  identify  the  configuration  documentation  for  selected  items  which  are  to  be 
integrated  or  interfaced  with  the  Cl,  such  as  items  separately  developed  or  currently  in  the  inventory. 

5.3.4. 1.2  Allocated  Configuration  Documentation  (ACD) 

The  contractor  shall  generate  the  documentation  required  for  the  allocated  baseline  as  specified  in  the  contract 
DD  Form  1423  for  each  Cl.  The  ACD  shall  define  requirements  allocated  from  the  FCD  or  from  a  higher  level 
Cl  to  a  lower  level  Cl.  The  ACD  for  the  Cl  shall  be  in  the  form  of  an  item  or  software  requirements 
specification,  and  other  referenced  documentation  (for  example,  Interface  Control  Documents,  Interface 
Requirements  Specifications  and  item  or  software  requirements  specifications  for  lower-level  CI(s),  if  any.  (For 
programs  or  contracts  involving  the  development  of  a  single  Cl,  the  Cl  specifications  may  serve  as  both  the 
functional  and  allocated  baselines.) 


5.3.4. 1.3  Product  Configuration  Documentation  (PCD). 

The  contractor  shall  generate  the  documentation  required  for  the  product  baseline  in  accordance  with  the 
requirements  in  the  contract  DD  Form  1423.  The  PCD  shall  be  in  the  form  of  item,  software,  material,  and 
process  specifications,  engineering  drawings,  software  architecture  and  design  products,  military  specifications, 
and  other  technical  documentation  comprising  a  complete  technical  data  package  for  the  CL  The  PCD  may  also 
be  in  the  form  of  the  actual  equipment  and/or  software  media.  The  PCD  shall  prescribe  the  necessary  physical 
and  functional  characteristics  of  the  Cl  and  the  verifications  required  to  demonstrate  required  performance. 

5.3.4.2  Maintenance  of  configuration  documentation. 

Once  the  related  configuration  baseline  has  been  established,  the  contractor  shall  control  and  maintain  the 
originals  of  the  current  approved  configuration  documentation  for  all  configuration  items  specified  in  the 
contract. 

5.3.5  Engineering  release  and  correlation  of  manufactured  products. 

The  contractor  shall  establish  and  maintain  an  engineering  release  system  and  shall  use  the  system  to  issue 
configuration  documentation  to  functional  activities  (e.g.,  manufacturing,  logistics,  quality  assurance, 
acquisition)  and  to  authorize  the  use  of  configuration  documentation  associated  with  an  approved  configuration. 
The  contractor  shall  maintain  current  and  historical  engineering  release  information  for  all  configuration 
documentation  of  all  configuration  items  and  their  component  parts.  The  engineering  release  system  shall 
interrelate  with  the  contractor’s  internal  system  of  controls  to  assure  that  all  engineering  changes  have  been 
incorporated  in  production  items  as  specified. 

5.3. 5.1  Specification  release  and  approval. 

If  Cl  specifications  are  a  contract  requirement,  the  contractor  shall  include  on  each  Cl  specification  a 
contractor’s  release  signature  indicating  that  the  document  has  been  reviewed  and  is  suitable  for  its  intended 
use.  In  addition,  the  contractor  shall  submit  each  such  specification  to  the  Government  for  an  approval  and 
authentication  signature.  Approval  and  authentication  by  the  Government  will  normally  be  accomplished  on  the 
version  of  the  specification  submitted  for  a  baseline.  Completion  of  the  release  and  approval  activities  indicates 
mutual  acceptance  by  the  Government  and  the  contractor  of  the  Cl’S  requirements,  as  defined  in  the 
specification  and  referenced  documents.  After  approval  and  authentication  and  contractual  implementation,  the 
specification  establishes  the  appropriate  baseline(s). 
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5.3. 5.2  Requirements  for  Engineering  Release  System 

5.3. 5.2.1  Engineering  Release  System  and  Use  of  Release  Records. 

The  contractor  shall  have  an  Engineering  Release  System  which  employs  formal  release  records  to  authorize 
the  use  of  new  or  revised  configuration  documentation.  The  contractor  shall  also  ensure  that  information  about 
the  new  approved  configuration  documentation  is  incorporated  into  their  CSA  information  system. 

5.3.6  Configuration  identifiers. 

CIs  and  their  configuration  documentation  shall  be  assigned  unique  identifiers  as  described  below. 

5.3. 6.1  CAGE  Code. 

The  design  activities  and  the  manufacturers  of  Cl’s  shall  be  identified  by  the  Government  assigned  CAGE 
Code,  which  shall  be  affixed  to  all  Cl’s,  their  subordinate  parts  and  assemblies,  configuration  documentation, 
software  media  and  products. 

5.3.6.2  Government  type  designators  and  nomenclature. 

Each  Cl  that  is  designated  by  the  Government  for  control,  tracking  and  logistics  purposes  shall  be  assigned 
Government  type  designators  and  nomenclature  in  accordance  with  the  requirements  of  the  contract. 

5.3.6.3  Document  numbers  . 

An  identification  number  shall  be  assigned  and  applied  to  specifications  and  to  all  revisions  thereto;  and  to 
engineering  drawings,  associated  lists  and  ancillary  documents  and  to  all  revisions  thereto.  (See  6.6) 

5.3. 6.4  Part/item  identification  numbers. 

A  discrete  part/item  identification  number  shall  be  assigned  to  each  Cl  and  its  subordinate  parts  and  assemblies 
and  be  changed  whenever  a  non-interchangeable  condition  is  created.  (See  6.6) 

5.3.6.5  Software  identifiers. 

For  each  CSCI,  the  contractor  shall  identify  its  corresponding  software  units.  For  each  CSCI  and  associated 
software  units  the  contractor  shall  issue/obtain  a  software  identifier,  which  shall  consist  of  a  name  or  number, 
and  a  version  identifier,  and  shall  relate  the  software  to  its  associated  software  design  documentation;  revision; 
and  release  date.  The  contractor  shall  embed  the  software  and  version  identifiers  within  the  source  code,  and 
provide  a  method  for  display  of  the  software  and  version  identifier  data  to  the  user  upon  command. 

5.3. 6.6  Serial/lot  numbers  . 

The  contractor  shall  assign  serial/lot  numbers  to  like  items,  or  to  groups  (lots)  of  like  items,  identified  with  a 
specific  Government  nomenclature,  unless  otherwise  specified  in  the  contract.  The  serial/lot  numbers  shall  be; 

•  A  maximum  of  15  alphanumeric  characters,  with  at  least  the  last  4  numeric. 

•  Unique,  consecutive,  and  non-duplicating  for  all  items  with  that  specific  nomenclature. 

5.3. 6. 6.1  Government  serial  numbers. 

The  Government  will  identify  the  serial  numbers  that  shall  be  affixed  to  Government  designated  deliverable  CIs 
by  the  contractor. 

5.3. 6. 6.2  Reuse  of  serial  numbers. 

The  original  serial  number  of  a  unit/item/CI  shall  not  be  changed  even  when  a  change  affecting 
interchangeability  may  require  rework  and  re-identification.  Once  assigned,  serial  numbers  shall  not  be  reused 
for  the  same  item/unit/CI. 

5.3. 6. 7  Product  identification/marking. 

Unless  otherwise  specified  in  the  contract,  all  CIs  including  parts,  assemblies,  units,  sets  and  other  pieces  of 
military  property  shall  be  marked  with  their  identifiers.  (See  6.6) 
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5.3. 6. 7.1  Software  marking  and  labeling. 

The  marking  and  labeling  of  software  shall  be  as  follows: 

•  Software  identifier  and  version  shall  be  embedded  in  the  source  code  header.  Automated  Computer 
Program  Identification  Numbers  (ACPINs)  may  be  required  in  the  case  of  software  expecting  depot 
level  maintenance  at  the  Warner  Robbins  depot.  If  so,  ACPIN  requests  shall  be  designated  as  a  unique 
contract  data  requirement. 

•  Each  software  medium  (e.g.,  magnetic  tape,  disk)  Containing  copies  of  tested  and  verified  software 
entities  shall  be  marked  with  a  label  containing,  or  providing  cross-reference  to,  a  listing  of  the 
applicable  software  identifiers  of  the  entities  it  contains. 

•  Media  for  deliverable  CSCIs/SIs  shall  be  labeled  with  The  Government  Contract  number,  CSCI/SI 
Number,  other  Government  identifier  (e.g.  ACPIN  if  applicable),  Design  activity  CAGE  Code,  Media 
Number  (e.g.,  1  of  2,  2  of  2)  if  there  are  multiple  units  per  set  and  copy  number  of  media  or  media  set 
(if  there  is  more  than  one  copy  being  delivered). 

•  Media  copy  numbers  shall  distinguish  each  copy  of  the  software  media  from  its  identical  copies.  Each 
time  a  new  version  of  software  is  issued,  new  copy  numbers,  starting  from  1,  shall  be  assigned. 

5.3. 6. 7.2 Firmware  labeling. 

Firmware  shall  be  labeled  on  the  device  or,  if  the  device  is  too  small,  on  the  next  higher  assembly,  as  follows: 

•  Where  both  the  hardware  device  and  the  embedded  code  are  controlled  via  a  single  engineering 
drawing,  the  part  number  representing  the  device  with  the  code  embedded  shall  comprise  the  label. 

•  Where  the  PCD  for  the  source  code  consists  of  a  Software  product  specification,  both  the  unloaded 
device  part  number  and  the  software  identifier  of  the  embedded  code,  including  version  number,  shall 
comprise  the  label.  In  addition,  the  software  identification(s)  shall  be  labeled  on  an  identification  plate 
or  decal  located  adjacent  to  the  nameplate  on  the  equipment  containing  the  firmware. 

5.3.6.7.3NDI,  COTS  ,  and  PDI  labeling. 

When  a  Cl  is  wholly  developed  with  private  funding  and  modified  to  satisfy  Government  requirements,  the  Cl 
shall  be  re-identified  as  a  Government  modified  Cl,  and  documented  and  controlled  in  accordance  with  the 
requirements  of  the  contract. 

5.3.7  Interface  management. 

5.3. 7.1  Interface  requirements. 

The  interface  requirements  for  the  system  and  its  configuration  items  shall  be  identified  as  a  part  of  the  system 
engineering  process.  Those  interface  requirements  which  must  be  controlled  by  the  Government  during  the 
development  of  the  system  shall  be  incorporated  into  the  FCD  and/or  ACD  as  applicable.  Such  interface 
requirements  defined  in  baselined  specifications  shall  be  subject  to  the  configuration  control  requirements  of 
this  TOR.  Prior  to  the  PBL,  the  contractor  shall  be  responsible  for  defining  and  controlling  all  interfaces  below 
the  ACD  level.  The  contractor  shall  ensure  the  compatibility  and  interoperability  among  the  various  hardware, 
software  and  firmware  components  for  which  they  are  the  design  activity  and  between  those  components  and 
the  interfaces/components  specified  in  the  baselined  configuration  documentation.  (See  6.3) 

5.3. 7.2  Requirements  for  an  Interface  Control  Working  Group  (ICWG). 

When  required,  the  use  of  an  ICWG  will  be  specified  by  the  contract  and  the  interface  control  contractor  will  be 
identified.  The  contractor  shall  establish  associate  contractor  agreements  with  interfacing  contractors  governing 
the  conduct  of  interface  control. 

5.3. 7.2.1  ICWG  membership. 

The  contractor  shall  be  responsible  for  providing  a  representative  to  the  ICWG  who  is  empowered  to  commit 
the  contractor  to  specific  interface  actions  and  agreements;  for  assuring  that  the  representative  is  present  at  all 
ICWG  meetings;  for  providing  draft  interface  control  documentation  at  a  specified  period  prior  to  the  ICWG 
meeting  where  it  will  be  discussed;  for  updating,  releasing,  and  controlling  interface  control  documentation 
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reflecting  the  ICWG  decisions;  and  for  distributing  copies  of  such  released  interface  control  documentation  to 
other  ICWG  participants. 

5.3. 7.2.2  ICWG  Chairmanship. 

The  contractor  designated  as  the  interface  control  contractor  shall  act  as  the  chair  for  the  ICWG  and  shall  be 
accountable  to  the  Government  to  report  interface  problems  as  they  are  surfaced  by  the  ICWG.  The  contractor 
shall  be  responsible  for  scheduling  ICWG  meetings;  for  providing  the  meeting  space  and  administrative 
support;  for  distributing  interface  control  documentation  to  be  addressed  at  the  upcoming  ICWG;  for  conducting 
the  ICWG  meetings;  for  making  interface  decisions  when  they  can  be  implemented  within  the  current  scope  of 
the  contracts  of  the  participants;  for  coordinating  ECPs  as  required;  for  recording  and  distributing  the  minutes  of 
the  ICWG  meetings;  and  for  ensuring  that  updated  interface  control  documentation  reflecting  the  ICWG 
decisions  is  distributed  within  the  time  frame  agreed  to  by  the  affected  participants.  (See  6.3) 

5.4  Configuration  control. 

Configuration  control  is  the  systematic  proposal,  justification,  evaluation,  coordination,  approval  or  disapproval 
of  proposed  changes,  and  the  implementation  of  all  approved  changes,  in  the  configuration  of  CIs  after 
establishment  of  the  configuration  baseline(s)  for  the  CIs. 

5.4.1  Purpose  of  configuration  control. 

The  contractor  shall  implement  a  configuration  control  function  that  ensures  regulation  of  the  flow  of  proposed 
changes,  documentation  of  the  complete  impact  of  the  proposed  changes,  and  release  only  of  approved 
configuration  changes  into  CIs  and  their  related  configuration  documentation.  Government  configuration 
control  begins  with  the  establishment  of  the  functional  baseline  and  continues  as  further  configuration  baselines 
are  established  for  the  CIs,  using  the  FCD,  the  ACD(s),  and  the  PCD(s)contractually  invoked  by  the 
Government.  The  contractors  are  responsible  for  configuration  control  of  their  respective  Developmental 
Baseline.  Configuration  control  continues  throughout  the  life  cycle  of  the  Cl.  The  following  requirements  shall 
apply  only  to  the  FCD,  the  ACD(s),  and  the  PCD(s)  which  have  been  authenticated/contractually  implemented 
by  the  Government. 

5.4.2  Requirements  for  Engineering  Change  Proposals. 

An  Engineering  Change  Proposal  shall  be  required  for  any  changes  to  any  government  approved  configuration 
documentation. 

5. 4.2.1  The  engineering  change  process. 

When  a  design  change  affects  documentation  baselined  by  the  government,  the  contractor  shall  ensure  the 
following  actions  at  a  minimum  are  included  in  their  configuration  control  process: 

•  Determination  of  a  need  for  the  change. 

•  Establishment  by  the  contractor  of  a  classification  of  the  engineering  change  as  Class  I  or  Class  II. 

•  Review  and  evaluation  of  the  change. 

•  Disposition  of  the  change. 

•  Preparation  of  an  ECP. 

•  Submittal  of  the  ECP  to  the  Government. 

•  Incorporation  of  approved  (or  concurred  in)  engineering  changes  in  the  documentation,  including, 
when  applicable,  negotiation  into  the  contract.  Implementation  of  the  change  in  accordance  with  the 
contract. 

Note:  Similar  steps  shall  apply  to  requests  for  deviations. 

5. 4.2.2  Administrative  requirements. 

5.4.2.2.1  Classification  of  engineering  changes. 

An  engineering  change  shall  be  classified  as  Class  I  or  Class  II  by  the,  preparing  contractor  in  accordance  with 
this  standard.  Class  I  ECPS  shall  be  referred  to  the  Government  for  approval  or  disapproval.  Classification 
disagreements  shall  be  referred  to  the  Government  Program  office  for  final  decision.  A  proposed  engineering 
change  to  a  Cl,  or  to  any  combination  or  discrete  portion  thereof,  shall  be  determined  to  be  Class  I  by 
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examining  the  factors  below,  as  contractually  applicable,  to  determine  if  they  would  be  impacted  as  a  result  of 
implementing  the  change. 

•  The  change  shall  be  Class  1  if  the  FCD  or  ACD,  once  established,  is  affected  to  the  extent  that  any  of 
the  following  requirements  would  be  outside  specified  limits  or  specified  tolerances: 

-  Performance. 

-  Reduction  of  reliability,  maintainability  or  survivability. 

-  Weight,  balance,  moment  of  inertia. 

-  Interface  characteristics. 

-  Electromagnetic  characteristics. 

-  Other  technical  requirements  in  the  specifications. 

Minor  clarifications  and  corrections  to  FCD  or  ACD  shall  be  requested  only  as  an  incidental  part  of  the  next 
Class  I  ECP  and  accompanying  SCN  or  NOR,  unless  otherwise  directed  by  the  Government. 

A  change  to  the  PCD,  once  established,  will  affect  the  FCD  or  ACD  as  described  in  5. 4. 2.2.1  or  will  impact  one 
or  more  of  the  following: 

•  GFE . 

•  Reduction  in  Safety. 

•  Compatibility  or  specified  interoperability  with  interfacing  CIS,  support  equipment  or  support 
software,  firmware  spares,  trainers  or  training  devices/equipment  or  software. 

•  Configuration  of  hardware,  software,  firmware  to  the  extent  that  retrofit  action  is  required. 

•  Delivered  operation  and  maintenance  manuals  for  which  adequate  change/revision  funding  is  not 
provided  in  existing  contracts. 

•  Preset  adjustments  or  schedules  affecting  operating  limits  or  performance  to  such  extent  as  to  require 
assignment  of  a  new  identification  number. 

•  Interchangeability,  substitutability,  or,  replace  ability  as  applied  to  CIS,  and  to  all  subassemblies  and 
parts  except  the  pieces  and  parts  of  non-reparable  subassemblies. 

•  Sources  of  CIs  or  repairable  items  at  any  level  defined  by  source-control  drawings. 

•  Skills,  manning,  training,  biomedical  factors  or  human  engineering  design. 

•  Any  of  the  following  contractual  factors  are  affected: 

•  Cost  to  the  Government  including  incentives  and  fees. 

•  Contract  guarantees  or  warranties. 

•  Contractual  deliveries. 

•  Scheduled  contract  milestones. 

5.4.2.2.2  Classifying  engineering  changes  to  a  privately  developed  item. 

An  engineering  change  to  a  PDI  shall  be  classified  Class  I  when  it  affects  the  contractually  specified  form,  fit, 
function,  or  logistics  support  of  an  item  or  factors  in  5. 4. 2.2.1.  When  a  greater  degree  of  control  is  negotiated 
between  the  Government  and  the  contractor,  effects  on  other  factors  may  be  added  to  the  effects  specified  in 
paragraph  5. 4. 2.2.1  that  classifies  an  engineering  change  as  Class  I. 

5.4.2.2.3  Content  of  Engineering  Change  Proposals  (ECPs). 

See  5. 4.2. 3. 5  and  5.4. 2.4.1. 

5.4.2.2.3.1  Unrelated  engineering  changes. 

A  separate  ECP  shall  be  required  for  each  engineering  change  which  has  its  own  distinct  objective. 

5.4.2.2.3.2  Revisions  of  ECPs. 

An  ECP  shall  be  revised  when  alterations  or  changes  to  the  initial  ECP  are  necessary.  The  first  revision  to  an 
ECP  shall  be  identified  by  the  entry  of  R1  in  the  revision  block  of  the  ECP.  Further  revisions  of  the  ECP  shall 
be  identified  by  the  entry  of  “R2”,  “R3”,  etc.  The  date  of  ECP  shall  be  the  submission  date  of  the  revision. 

•  Major  revisions  to  an  ECP  shall  be  made  as  a  complete  revised  and  resubmitted  package. 

•  Minor  revisions  to  an  ECP  (such  as  those  which  correct  errors,  add  or  delete  information,  update 
pricing,  or  provide  clarifications)  may  be  made  by  attaching  new  or  revised  pages,  indicating  the  new 
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date  and  revision  level  on  each  such  page  of  the  ECP.  This  will  also  necessitate  changing  the  cover 
page  date  and  revision  level  even  if  no  other  data  on  that  cover  sheet  changed. 

•  In  either  case,  the  information  which  differs  from  the  original  ECP  shall  be  clearly  identified  in  a 
manner  similar  to  the  marking  of  change  pages  for  specifications.  The  ECP  should  clearly  include 
information  as  to  whether  the  revision  is  a  re-  submittal  (replacing  the  existing  ECP  in  its  entirety)  or 
solely  provides  change  pages  and  a  revised  cover  page  to  the  existing  ECP. 

5.4.2.2.3.3  Supporting  data. 

Formal  ECPs  shall  be  supported  by  drawings  and  other  data  (e.g.,  LSA  data,  detailed  cost  proposal  data,  test 
data  and  analyses)  as  specified  in  the  contract  to  justify  and  describe  the  change  and  to  determine  its  total 
impact  including  assessments  of  changes  to  system  operational  employment  characteristics.  When  a  life  cycle 
cost  and/or  operation  and  support  cost  model  has  been  included  in  the  contract,  the  ECP  shall  also  include  the 
costs  expected  to  result  from  the  implementation  of  this  change  into  all  future  production  and  spare  items 
projected  to  be  procured  for  the  program  and  all  projected  operation  and  support  costs  for  operation  of  the  total 
inventory  of  items  by  the  Government.  A  summary  of  any  testing  done  by  the  contractor  to  validate  concepts  or 
new  technology  to  be  employed  in  the  proposed  engineering  change  shall  be  presented  in  the  supporting  data, 
and  details  of  such  test  data  shall  be  provided  if  it  is  vital  to  the  decision  regarding  acceptance  of  the  change. 

5.4.2.2.3.4  Classified  data 

When  practicable,  the  ECP  should  be  unclassified.  Classified  data  essential  to  the  evaluation  and  disposition  of 
an  ECP  shall  be  submitted  separately  in  accordance  with  the  approved  security  procedures  and  referenced  in  the 
unclassified  portion  of  the  ECP.  The  contractual  DD  Form  254  or  DoD  Contract  Security  Classification 
Specification  applies. 

5.4.2.3  Class  I  engineering  change  proposals. 

Class  I  engineering  changes  should  be  limited  to  those  which  are  necessary  or  offer  significant  benefit  to  the 
Government.  Such  changes  are  those  required  to: 

•  Correct  deficiencies. 

•  Add  or  modify  interface  or  interoperability  requirements. 

•  Make  a  significant  and  measurable  effectiveness  change  in  the  operational  capabilities  or  logistics 
supportability  of  the  system  or  item. 

•  Effect  substantial  life  cycle  costs/savings,  or 

•  Prevent  slippage  in  an  approved  production  schedule. 

5.4.2.3.1  Class  I  ECP  decisions. 

5.4.2.3.1.1  Target  for  technical  decision  on  Class  I  ECPS. 

The  criticality  of  the  need  for  decision  will  dictate  the  actual  processing  time  for  ECPS.  Emergency  and  urgent 
ECPS  should  be  proposed  based  upon  the  targets  below  unless  otherwise  agreed  to  between  the  contractor  and 
the  Government.  Processing  targets  for  routine  ECPS  will  be  tailored  to  maximize  cost  effectiveness, 
recognizing  the  program,  system,  and  ECP  complexity.  The  target  for  technical  decision  on  Class  I  ECPS 
assigned  the  various  priorities  (defined  in  paragraph  5. 4. 2. 3. 4)  will  be  the  following: 

•  Emergency  48  hours 

•  Urgent  30  calendar  days 

•  Routine  90  calendar  days 

5.4.2.3.1.2  ECP  authorization. 

Unless  otherwise  specified  by  the  Government,  receipt  of  contractual  authorization  shall  constitute  the  sole 
authority  for  the  contractor  to  implement  a  Class  I  change.  Authorization  of  the  change  granted  by  the 
Government  will  include  reference  to  the  ECP  by  number,  revision  (if  applicable) ,  and  date.  Such  authorization 
will  normally  not  occur  until  the  Government  has  performed  a  review  for  technical  adequacy  and  supportability. 
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5. 4.2.3. 1.3  Class  I  compatibility  engineering  changes. 

This  category  of  change  is  intended  to  allow  expeditious  corrective  action  when  the  need  for  a  change  has  been 
discovered  during  system  or  item  functional  checks  or  during  installation  and  checkout.  The  contractor  shall 
notify  the  Government  by  written  message  within  48  hours  after  determining  that  a  compatibility  change  is 
necessary.  The  message  shall  define  the  need  for  a  compatibility  change  and  identify  factors  that  will  be 
impacted,  including  estimated  costs  and  schedules.  Unless  otherwise  prohibited  by  the  contract,  corrective 
action  may  then  be  implemented  immediately  by  the  contractor  to  resolve  such  incompatibilities,  but  only  for 
the  specific  item(s)  situated  in  the  location  at  which  the  deficiency  was  originally  discovered.  All  aspects  of  the 
compatibility  definition  must  apply.  In  addition,  a  Class  I  compatibility  ECP  shall  be  required  within  30  days 
after  initial  notification.  Where  further  action  is  necessary  due  to  “lead  time”  considerations,  the  contractor  may 
initiate  procurement  or  manufacturing  action  and  shall  advise  the  Government  with  a  change  message 
referencing  the  serial  number(s)  and  locations  of  additional  items  involved.  The  contractor  assumes  total  risk  for 
implementation  of  such  a  change  prior  to  Government  authorization,  except  in  those  cases  where  the 
Government  caused  the  incompatibility. 

5. 4.2.3. 1.4  Disapproval  of  ECPS. 

When  the  Government  disapproves  an  ECP,  the  originator  will  be  notified  in  writing  within  30  calendar  days  of 
the  decision  and  will  be  given  the  reason(s)  for  the  disapproval. 

5.4.2.3.2  Class  I  ECP  justification  codes. 

Justification  codes  corresponding  with  the  criteria  necessary  for  beneficial  engineering  changes  are  listed  below. 
If  more  than  one  of  these  codes  are  applicable,  the  one  which  is  the  most  descriptive  or  significant  shall  be 
assigned  to  the  ECP. 

•  Interface  (Code  B).  Code  B  shall  be  assigned  to  an  engineering  change  proposed  to  eliminate 
incompatibility  between  CIs. 

•  Compatibility  (Code  C).  Code  C  shall  be  assigned  to  an  engineering  change  to  correct  a  deficiency 
with  the  following  characteristics: 

1)  The  need  for  the  change  has  been  discovered  during  the  system  or  item  functional  checks  or  during 
installation  and  checkout  and  is  necessary  to  make  the  system  or  item  work. 

2)  By  assigning  the  compatibility  code  the  contractor  is  declaring  that  the  effort  required  to  accomplish 
the  change  is  considered  to  be  within  the  scope  of  the  existing  contract  except  for  changes  caused  by 
the  Government. 

3)  Contractual  coverage  completing  the  formal  documentation  of  the  engineering  change  will  not 
reflect  an  increase  in  contract  price  for  the  corrective  action  in  production  and  to  delivered  items  in¬ 
warranty  or  otherwise  stipulated  in  the  contract. 

•  Correction  of  deficiency  (Code  D).  Code  D  shall  be  assigned  to  an  engineering  change  which  is 
required  to  eliminate  a  deficiency,  unless  a  more  descriptive  separate  code  applies,  Such  separate  codes 
are  used  to  identify  deficiencies  of  the  nature  of  safety,  interface,  compatibility. 

•  Operational  or  logistics  support  (Code  O).  Code  O  shall  be  assigned  to  an  engineering  change  which 
will  make  a  significant  effectiveness  change  in  operational  capabilities  or  logistics  support. 

•  Production  stoppage  (Code  P).  Code  P  shall  be  assigned  to  an  engineering  change  which  is  required  to 
prevent  slippage  in  an  approved  production  schedule.  This  code  applies  when  production  to  the  current 
configuration  documentation  either  is  impracticable  or  cannot  be  accomplished  without  delay. 

•  Cost  reduction  (code  R).  Code  R  shall  be  assigned  to  An  engineering  change  which  will  provide  a  net 
total  life  cycle  cost  savings  to  the  Government,  but  which  is  not  being  submitted  pursuant  to  the  Value 
Engineering  clause  of  the  contract.  The  savings  in  life  cycle  cost  should  include  all  effects  on  cost  and 
price  for  the  effort  and  requirements  covered  by  the  contract(s)  currently  in  effect  for  this  contractor, 
plus  the  costs  resulting  from  necessary  associated  changes  in  delivered  items,  and  logistics  support. 

•  Safety  (Code  S).  Code  S  shall  be  assigned  to  an  engineering  change  for  correction  of  a  deficiency 
which  is  required  primarily  to  eliminate  a  hazardous  condition.  When  this  code  is  assigned,  a  system 
hazard  analysis  shall  be  included  with  the  ECP.  (See  6.6) 

•  Value  engineering  (VE)  (Code  V).  Code  V  shall  be  assigned  to  an  engineering  change  which  will 
effect  a  net  life  cycle  cost  reduction  and  which  is  submitted  pursuant  to  the  VE  clause  of  the  contract. 
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5.4.2.3.3  Class  I  ECP  types. 

There  are  two  types  of  Class  I  ECPs,  preliminary  and  formal.  The  type  of  Class  I  ECP  appropriate  to  the 
circumstances  shall  be  selected  in  accordance  with  the  following  definitions  and  guidelines. 

5.4.2.3.3.1  Preliminary  change  proposal. 

A  preliminary  change  proposal  is  the  type  which  may  be  submitted  to  the  Government  for  review  prior  to  the 
availability  of  the  information  necessary  to  support  a  formal  ECP.  It  shall  include  a  summary  of  the  proposed 
change,  its  impact  on  related  areas,  and  a  justification. 

5.4.2.3.3.1.1  Use  of  preliminary  ECPs  (Type  P). 

A  preliminary  ECP  may  be  prepared  and  submitted  for  one  of  the  following  purposes: 

•  To  furnish  the  Government  with  available  information  in  order  to  permit  a  preliminary  evaluation 
relative  to  the  merits  of  the  proposed  change  (e.g.  installation  of  a  proposed  change  for  the  purpose  of 
evaluation  and  testing  prior  to  making  a  final  decision  to  proceed  with  a  proposed  change), 

•  To  provide  a  determination  regarding  the  desirability  of  continuing  expenditures  required  to  further 
develop  the  proposal, 

•  To  provide  alternative  proposals, 

•  To  supplement  a  message  relative  to  an  emergency  or  urgent  priority  ECP  when  it  is  impracticable  to 
submit  a  formal  ECP  within  30  calendar  days, 

•  To  propose  a  software  change  prior  to  the  development  of  the  actual  coding  changes  and  to  obtain 
Government  approval  to  proceed  with  software  engineering  development. 

5.4.2.3.3.2  Use  of  Formal  ECP  (Type  F). 

A  formal  ECP  is  the  type  which  provides  engineering  information-and  other  data  in  sufficient  detail  to  support 
formal  change  approval/contractual  implementation. 

5.4.2.3.4  Class  I  engineering  change  priorities. 

A  priority  shall  be  assigned  to  each  Class  I  ECP  based  upon  the  following  definitions.  The  assigned  priority  will 
determine  the  time  frame  in  which  the  ECP  is  to  be  reviewed,  evaluated,  ordered,  and  implemented.  The 
proposed  priority  is  assigned  by  the  originator  and  will  stand  unless  the  Government  has  a  valid  reason  for 
changing  the  priority. 

1.  Emergency.  An  emergency  priority  shall  be  assigned  to  an  change  proposed  for  any  of  the  following: 

a.  To  effect  a  change  in  operational  characteristics  which,  if  not  accomplished  without  delay, 
may  seriously  compromise  national  security; 

b.  To  correct  a  hazardous  condition  which  may  result  in  fatal  or  serious  injury  to  personnel  or  in 
extensive  damage  or  destruction  of  equipment.  (A  hazardous  condition  usually  will  require 
withdrawing  the  item  from  service  temporarily,  or  suspension  of  the  item  operation,  or 
discontinuance  of  further  testing  or  development  pending  resolution  of  the  condition.);  or 

c.  To  correct  a  system  halt  (abnormal  termination)  in  production  environment  such  that  CSCI 
mission  accomplishment  is  prohibited. 

2.  Urgent.  An  urgent  priority  shall  be  assigned  to  an  engineering  change  proposed  for  any  of  the 
following  reasons: 

a.  To  effect  a  change  which,  if  not  accomplished  expeditiously,  may  seriously  compromise  the 
mission  effectiveness  of  deployed  equipment,  software,  or  forces;  or 

b.  To  correct  a  potentially  hazardous  condition,  the  uncorrected  existence  of  which  could  result 
in  injury  to  personnel  or  damage  to  equipment.  (A  potentially  hazardous  condition 
compromises  safety  and  embodies  risk,  but  within  reasonable  limits,  permits  continued  use  of 
the  affected  item  provided  the  operator  has  informed  of  the  hazard  and  appropriate 
precautions  been  defined  and  distributed  to  the  user.);  or 

c.  To  meet  significant  contractual  requirements  (e.g.,  when  lead  time  will  necessitate  slipping 
approved  production  or  deployment  schedules  if  the  change  was  not  incorporated) ;  or 

d.  To  effect  an  interface  change  which,  if  delayed,  would  cause  a  schedule  slippage  or  increase 
cost;  or 
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e.  To  effect  a  significant  net  life  cycle  cost  savings  to  the  Government,  as  defined  in  the 
contract,  through  value  engineering  or  through  other  cost  reduction  efforts  where  expedited 
processing  of  the  change  will  be  a  major  factor  in  realizing  lower  costs. 

f.  To  correct  unusable  output  critical  to  mission  accomplishment; 

g.  To  correct  critical  Cl  files  that  are  being  degraded;  or 

h.  To  effect  a  change  in  operational  characteristics  to  implement  a  new  or  changed  regulatory 
requirement  with  stringent  completion  date  requirements  issued  by  an  authority  higher  than 
that  of  the  functional  proponent. 

3.  Routine.  A  routine  priority  shall  be  assigned  to  a  proposed  engineering  change  when  emergency  or 
urgent  is  not  applicable. 


5.4.2.3.4.1  Expediting  Class  I  engineering  changes  with  priority  of  emergency  or  urgent. 

ECPs  carrying  a  priority  of  emergency  shall,  and  ECPS  carrying  a  priority  of  urgent  may,  be  reported  to  the 
Government  by  telephone,  message,  personal  contact,  electronic  transmission  or  other  expeditious  means.  All 
communications  shall  be  identified  by  the  ECP  number.  If  the  initial  communication  regarding  a  proposed 
change  was  by  other  than  written  message,  it  shall  be  confirmed  by  written  message  in  the  appropriate  format 
within  24  hours,  and  followed  by  a  formal  ECP  within  30  days  after  the  first  communication  unless  otherwise 
specified  by  the  Government.  However,  if  it  is  impractical  to  complete  a  formal  ECP  within  30  days  due  to  the 
necessity  for  extensive  development,  a  preliminary  ECP  may  be  submitted  within  a  30  day  Period  followed  by  a 
formal  ECP  at  a  specified  interval  thereafter.  The  preliminary  or  formal  ECP  shall  carry  the  same  ECP  number 
as  the  written  message  and  shall  include  reference  to: 

•  Method  and  date  of  the  original  communication. 

•  Individuals  contacted. 

•  Source  of  resultant  contractual  direction,  if  any. 

5. 4.2.3. 5  Format  for  Class  I  engineering  changes. 

Contractor  format  is  acceptable  for  proposing  Class  I  engineering  changes,  as  long  as  ECP  information 
presented  in  TOR  -  CM  Data  Items  is  fully  presented.  Unclear  or  incomplete  information  delays  government 
configuration  management  processing  of  contractor  requested  ECPs. 

5. 4.2.3. 6  Related  engineering  changes. 

5. 4.2.3. 6.1  Related  engineering  changes-single  prime. 

A  desired  engineering  change  in  one  item  (the  basic  engineering  change)  may  require  related  engineering 
changes  in  other  items  in  order  to  retain  (or  attain)  either  an  interface  match  or  compatibility  and 
interoperability  of  associated  items.  When  such  an  engineering  change  is  proposed  and  when  the  basic  item  and 
other  items  affected  by  related  engineering  changes  are  the  responsibility  of  a  single  prime  contractor,  the  ECP 
package  shall  include  both  the  basic  and  all  such  related  engineering  changes. 

5. 4.2.3. 6.2  Related  engineering  changes  -  single  prime  multiple  procuring  activities  . 

The  basic  ECP  number  shall  be  assigned  to  the  ECP  applicable  to  the  item  which  is  the  immediate  objective  of 
the  desired  ECP.  Related  ECPS  submitted  to  the  Government  shall  be  identified  by  the  basic  number  plus  a 
separate  dash  number  for  each  procurement  activity. 

5. 4.2.3. 6.3  Related  engineering  changes  -  separate  primes. 

When  a  desired  engineering  change  in  one  item  (the  basic  engineering  change)  requires  related  engineering 
changes  in  other  items  which  are  the  responsibility  of  other  prime  contractors  who  are  participating  in  a  specific 
item  development  or  production  program,  the  basic  ECP  and  its  impact  on  other  items  shall  be  coordinated  by 
the  originating  contractor  as  required  prior  to  submission  to  the  Government.  Coordinating  contractors  are  not 
required  to  provide  cost  and  pricing  data  to  other  contractors.  The  technical  basis  for  the  change  and  technical 
effects  of  the  change  shall  be  coordinated.  The  coordinated  basic  ECP  shall  include  data  showing  the  extent  of 
coordination  and  its  results,  when  applicable  and  available,  to  the  related  ECPS  of  the  other  prime  contractors. 
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Likewise,  the  basic  and  each  related  ECP,  when  submitted  by  its  separate  prime,  shall  cross-reference  the  basic 
and  other  related  ECPS. 

5. 4.2.3. 6.4  Same  engineering  change  prime/subcontractor  coordination. 

When  the  contractor,  as  the  prime  contractor  to  the  Government  for  an  item,  is  also  a  subcontractor  to  another 
prime  contractor(s)  for  that  same  item,  initiates  an  ECP  on  that  item,  he  shall  coordinate  the  ECP  with  the  other 
prime  contractor(s)  Prior  to  submission.  The  ECP  shall  include  data  on  the  extent  and  results  of  such 
coordination. 

5. 4.2.3. 6. 5  Same  engineering  change  several  contractors. 

Unless  otherwise  specified,  when  the  Government  has  contracts  with  two  or  more  prime  contractors  for  the 
same  item,  the  Government  will  conduct  such  coordination  of  ECPS  as  it  deems  necessary. 

5. 4.2.4  Class  II  engineering  changes. 

An  engineering  change  which  impacts  none  of  the  Class  1  factors  specified  in  5. 4. 2.2.1  shall  be  classified  as  a 
Class  II  engineering  change.  Generally,  Class  II  ECPs  are  limited  to  administrative/documentation 
clarifications/corrections. 

5. 4.2.4. 1  Class  II  engineering  change  format. 

•  Contractor  format  is  acceptable  for  proposing  Class  II  engineering  changes.  As  in  Class  I  ECPs, 
information  shall  be  clearly  presented  to  avoid  processing  delays. 

5.4.2.4.2  Class  II  justification  codes. 

The  justification  codes  for  Class  I  engineering  changes  need  not  be  applied  to  a  Class  II  engineering  change. 

5.4.2.4.3  Concurrence  in  Class  II  changes. 

Unless  otherwise  specified  by  the  Government,  or  unless  5. 4. 2. 4. 4  or  5. 4. 2. 4. 5  applies,  Government  review  of 
Class  II  changes  during  production  will  consist  of  a  technical  evaluation  of  the  change  and  of  material 
substitutions  to  support  concurrence  in  classification  recommendations.  The  contractor  shall  obtain  Government 
concurrence  prior  to  or  concurrent  with  the  release  of  any  Class  II  change.  The  contractor  assumes  total  risk  for 
implementation  of  changes  prior  to  receiving  notification  of  Government  concurrence. 

,5.4.2.4.4  Approval  of  Class  II  changes. 

In  the  event  the  Government  has  required  by  contract  that  it  approve  each  Class  II  change,  the  contractor  shall 
not  implement  the  change  until  it  is  approved  by  the  Government. 

5.4.2.4.5  Non-custody  of  the  original  drawings. 

When  the  contractor  or  his  subcontractors  do  not  have  custody  of  the  original  drawings  delineating  the  detail 
design,  and  when  compliance  with  such  drawings  is  a  contract  requirement,  each  Class  II  engineering  change  is 
subject  to  approval  by  the  Government  prior  to  implementation  as  specified  in  the  contract. 

5.4.3  Requirements  for  Requests  for  Deviation  (RFD). 

The  contractor  shall  not  manufacture  items  for  acceptance  by  the  Government  that  incorporate  a  known 
departure  from  requirements,  unless  a  request  for  a  deviation  has  been  approved  in  accordance  with  the 
requirements  of  this  standard.  Authorized  deviations  are  a  temporary  departure  from  requirements  and  do  not 
constitute  a  change  to  the  FCD,  ACD,  or  PCD.  Before  or  after  manufacture  of  an  item,  if  a  contractor  considers 
it  necessary  to  temporarily  depart  from  the  requirements,  the  contractor  may  request  a  deviation.  Deviation 
requests  which  include  the  use  of  parts/materials  not  in  conformance  with  the  approved  engineering 
documentation  (e.g.  repairs)  must  identify  the  unique  identity  assigned  to  discrepant  parts/materials  and  certify 
that  status  accounting  records  and  all  other  associated  documentation  shall  indicate  that  alternate  identification 
for  the  specific  units  for  which  relief  is  being  requested  in  the  RFD.  Deviations  do  not  apply  to  software  code 
listings.  Where  it  is  determined  that  a  change  should  be  permanent,  a  Class  I  or  Class  II  engineering  change 
must  be  processed  in  accordance  with  this  standard. 
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5. 4.3.1  Restrictions  on  deviations. 

Unless  unusual  circumstances  exist,  critical  deviations  and  deviations  which  would  affect  service  operation, 
logistic  interoperability,  or  maintenance  (e.g.,  repair  parts,  operation  or  maintenance  procedures,  or 
compatibility  with  trainers  or  test  sets)  shall  not  be  requested.  The  effectively  of  the  request  for  deviation 
normally  should  not  include  the  entire  remaining  number  of  deliverable  units  on  the  contract;  if  that  is  the  case, 
an  engineering  change  should  be  submitted. 

5. 4.3.2  Recurring  deviations. 

Submittal  of  recurring  deviations  is  discouraged  and  shall  be  minimized.  If  a  proposed  deviation  is  recurring  (a 
repetition  or  extension  of  a  previously  approved  deviation),  it  is  probable  that  either  the  requirements  of  the 
documentation  are  too  stringent  or  the  corrective  action  of  the  manufacturer  was  ineffective.  If  it  is  necessary 
for  a  contractor  to  request  a  deviation  for  the  same  situation  with  the  same  item  more  than  two  times,  then  the 
need  for  an  engineering  change,  rather  than  deviation,  shall  be  addressed  between  the  Government  and  the 
contractor. 

5. 4.3.3  Classification  of  deviations. 

Each  request  for  deviation  shall  be  designated  as  critical,  major,  or  minor  by  the  originator  in  accordance  with 
this  standard.  Classification  disagreements  shall  be  referred  to  the  Government  Program  Office  for  decision. 

5.4.3 .3.1  Minor. 

A  deviation  shall  be  designated  as  minor  when: 

•  The  deviation  consists  of  a  departure  which  does  not  involve  any  of  the  factors  listed  in  5. 4. 3. 3. 2  or 

5.4.33.3  or 

•  When  the  configuration  documentation  defining  the  requirements  for  the  item  classifies  defects  in 
requirements  and  the  deviations  consist  of  a  departure  from  a  requirement  classified  as  minor. 

5.4.3 .3.2  Major. 

A  deviation  shall  be  designated  as  major  when: 

•  The  deviation  consists  of  a  departure  involving: 

(1)  health;  (2)  performance;  (3)  interchangeability,  reliability,  survivability,  maintainability,  or 
durability  of  the  item  or  its  repair  parts;  (4)  effective  use  or  operation;  (5)  weight;  or  (6) 
appearance  (when  a  factor)  or 

•  When  the  configuration  documentation  defining  the  requirements  for  the  item  classifies  defects  in 
requirements  and  the  deviations  consist  of  a  departure  from  a  requirement  classified  as  major. 

5.4.3.3.3  Critical. 

A  deviation  shall  be  designated  as  critical  when: 

•  The  deviation  consists  of  a  departure  involving  safety  or 

•  When  the  configuration  documentation  defining  the  requirements  for  the  item  classifies  defects  in 
requirements  and  the  deviations  consist  of  a  departure  from  a  requirement  classified  as  critical. 

5.4.3.4  Format. 

Contractor  format  for  the  Request  for  Deviation  (RFD)  is  acceptable.  Each  RFD  shall  contain  all  information 
(presented  in  TOR  Configuration  Management  Data  Items)  required  for  the  government  to  disposition  it  as 
expeditiously  as  practicable. 

5.4.3. 5  Disposition  of  deviations. 

Unless  otherwise  specified  in  the  contract,  requests  for  deviations  should  be  approved  or  disapproved  within  30 
calendar  days  of  receipt  by  the  Government. 
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5.4.4  Part  substitutions. 

Unless  otherwise  specified  by  contract,  part  substitution  for  parts  identified  in  the  government  approved 
configuration  documentation  of  an  item  from  the  product  baseline  through  the  remainder  of  the  item’s  life  cycle 
shall  conform  as  follows: 

•  Substitution  of  a  non-repairable  part  for  an  item  for  which  the  contractor  has  configuration 
documentation  custody  shall  require  a  Class  I  or  Class  II  engineering  change  or  a  request  for  deviation 
or  waiver  when: 

-  The  part  is  identified  as  an  authorized  substitute  or  superseding  part  in  a  military  specification  or 
standard;  and  the  part  will  not  be  installed  in  equipment  to  be  submitted  for  verification  and 
reliability  demonstration  tests. 

•  Substitution  of  a  non-repairable  part  shall  require  a  Class  II  engineering  change  when: 

-  The  part  substituted  is  determined,  by  the  contractor  having  configuration  documentation  custody 
over  the  item,  to  be  a  preferred  part  over  the  original;  or  the  contractor  does  not  have  configuration 
documentation  custody. 

•  Part  substitutions  which  do  not  meet  the  requirements  of  5.4.5a  or  5.4.5b  and  for  which  a  permanent 
change  is  not  desired  shall  require  submission  of  a  Request  for  Deviation  (RFD). 

•  All  other  parts  substitutions  shall  be  subject  to  the  Class  I  or  Class  II  engineering  change  applicable. 

5.4.5  Requirements  for  Specification  Change  Notices  (SCNs). 

In  accordance  with  the  requirements  of  the  contract,  the  contractor  shall,  concurrent  with  the  preparation  of  an 
ECP,  prepare  a  separate  proposed  Specification  Change  Notice  for  each  specification  which  would  require 
revision  if  the  ECP  were  approved.  The  SCN(s)  shall  be  submitted  to  the  Government  with  the  ECP  for 
approval  and  authorization,  or  disapproval.  In  the  situation  discussed  in  paragraph  5. 4. 2. 3. 6. 3  (Related 
engineering  changes  -  separate  primes),  the  originating  contractor  shall  prepare  and  coordinate  the  SCN(s)  with 
other  prime  contractors  along  with  the  ECP.  Errors  of  a  minor  nature  (such  as  typographical  errors,  punctuation, 
etc.)  shall  not  be  corrected,  except  as  an  incidental  part  of  the  next  technically  required  ECP  and  accompanying 
proposed  SCN  affecting  that  Cl  specification.  (See  4.3.2  and  6.3)  SCNs  shall  be  prepared  in  accordance  with 
the  requirements  delineated  in  the  contract  DD  Form  1423. 

5. 4. 5.4  Approved  SCN. 

The  contractor  will  receive  approved  SCNs  from  the  Government  concurrent  with  contractual  authorization,  and 
shall  use  the  approved  SCNs  as  authorization  to  update  the  specifications  in  accordance  with  the  approved 
SCNs.  An  approved  SCN  also  provides  a  summary  listing  of  pages  affected  by  all  previously  approved  changes 
to  that  particular  revision  of  the  specification.  SCNS  are  not  cumulative  insofar  as  transmittal  of  change  pages 
from  previous  change  is  concerned,  and  changes  distributed  with  previous  SCNs  remain  in  effect  unless 
changed  or  canceled  by  an  SCN  of  later  issue.  However,  the  summary  of  current  changes  shall  be  a  cumulative 
summary  as  of  the  date  of  approval  of  the  latest  SCN. 

5.4.5.5  Changed  pages. 

Updated  and  reissued  pages  shall  be  complete  reprints  of  pages  suitable  for  incorporation  by  removal  of  old 
pages  and  insertion  of  new  pages.  All  portions  affected  by  the  change  shall  be  indicated  by  a  symbol  in  the 
margin  adjacent  to  the  change  and  encompassing  all  changed  portions.  When  changed  pages  are  issued  for 
specifications  with  pages  printed  on  both  sides  of  a  sheet,  and  only  the  page  on  side  of  a  sheet  is  affected  by  the 
change,  both  sides  of  the  sheet  shall  be  reissued.  The  unchanged  side  shall  be  reprinted  without  change  and  shall 
not  carry  the  date  of  the  change  or  be  included  in  the  change  summary  as  being  affected  by  the  change. 

5.4.6  Requirements  for  Notices  of  Revision  (NORs). 

The  Notice  of  Revision  shall  be  prepared  and  utilized  by  contractors  to  describe  the  exact  change(s)  to  be  made 
to  each  drawing,  associated  list,  or  other  affected  document  when  specified  as  a  data  requirement  in  the  contract 
DD  Form  1423.  NORs  shall  be  prepared  in  contractor  format  containing  all  information  required  to  disposition 
the  NOR  and  its  associated  ECP.  NORs  are  normally  applicable  where  documents  affected  by  the  ECP  are  not 
controlled  by  the  ECP  preparing  activity. 
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5.5  Configuration  Status  Accounting  (CSA). 

5.5.1  Purpose  of  CSA. 

The  purpose  of  CSA  is  to  assure  accurate  identification  of  each  Cl,  and  delivered  unit  so  that  the  necessary 
logistics  support  elements  can  be  correctly  programmed  and  made  available  in  time  to  support  the  CL  An 
adequate  and  accurate  CSA  will  enhance  program  and  functional  manager’s  capabilities  to  identify,  produce, 
inspect,  deliver,  operate,  maintain,  repair,  refurbish,  etc.,  CIS  in  a  timely,  efficient,  and  economical  manner  in 
satisfying  their  assigned  responsibilities. 

5.5.2  CSA  requirements . 

The  contractor  shall  implement  an  information  system  capable  of  meeting  contractual  requirements  for  CSA. 

5.5.3  Preferred  information  system. 

The  contractor  shall  provide  CSA  information  from  the  contractor’s  information  system  to  the  maximum  extent 
possible.  Where  information  beyond  the  existing  contractor  system  is  required  by  the  Government  to  be 
included  in  data  base  or  in  the  formatted  output,  such  additional  information  shall  be  provided  as  supplements  to 
the  existing  system  without  disrupting  the  existing  system  or  requiring  the  generation  of  a  completely  new 
system  for  the  Government. 

5.5.4  Retention  of  historical  data  base. 

The  contractor  shall  retain  a  complete  historical  record  of  all  the  information  required  by  the  Government  to  be 
stored  in  the  system.  Such  historical  information  shall  be  formatted  and  maintained  in  such  a  manner  that  it  can 
readily  be  copied,  in  total  or  by  specific  elements  identified  by  the  Government,  for  transfer  in  a  format 
specified  in  the  contract. 

5.5.5  CSA  data  elements. 

Deleted 

5.5.6  Contractor  focal  point . 

The  contractor  shall  identify  a  focal  point  for  the  CSA  system  to  interface  with  the  data  base  users. 

5.5.7  CSA  analysis  requirements. 

The  contractor  shall  ensure  the  validity  of  their  CSA  data.  When  potential  or  actual  problems  or  delinquencies 
which  impact  the  Government  are  detected,  the  contractor  shall  contact  the  Government  within  one  business 
day  to  establish  a  course  of  action  to  rectify  the  situation.  In  addition: 

•  Analysis  shall  be  performed  to  detect  trends  in  the  problems  reported. 

•  Corrective  actions  shall  be  evaluated  to:  (1)  verify  that  problems  have  been  resolved,  adverse  trends 
have  been  reversed,  and  changes  have  been  correctly  implemented  in  the  appropriate  processes  and 
products,  and  (2)  to  determine  whether  additional  problems  have  been  introduced. 

5.5.8  Reporting  accomplishment  of  retrofit  changes. 

When  units  already  accepted  by  the  Government  are  returned  to  the  contractor,  either  for  prolonged  use  or  for 
specific  retrofit  action,  the  contractor  shall  document  the  incorporation  of  all  retrofit  changes  to  those  units  in 
his  custody  and  shall  report  the  status  of  those  units  in  the  CSA  records 

5.6  Configuration  audits. 

FCA  and  PCAs  will  normally  be  conducted  by  the  Government  prior  to  acceptance  of  a  Cl  and  prior  to 
establishing  the  PBL. 

5.6.1  Contractor  participation  and  responsibilities. 

The  contractor  shall  be  responsible  for  supporting  Government  conducted  configuration  audits  in  accordance 
with  the  following  requirements  except  as  amended  by  the  contract. 
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5.6.1. 1  Subcontractors  and  suppliers  . 

The  contractor  shall  be  responsible  for  insuring  that  subcontractors,  vendors,  and  suppliers  participate  in 
Government  configuration  audits,  as  appropriate. 

5. 6. 1.2  Location. 

•  Unless  otherwise  specified  in  the  Contract  Statement  of  Work  (SOW),  the  configuration  audits  shall  be 
conducted  at  the  contractor’s  facility  or  at  a  designated  subcontractor  facility,  if  approved  by  the 
Government.  Accordingly,  the  contractor  shall  be  required  to  provide  the  necessary  resources  and 
material  to  perform  the  audit  effectively.  If  a  Configuration  Management  Plan  is  a  requirement  of  the 
contract  DD  Form  1423,  it  shall  include  all  information  required  to  assure  the  proper  conduct  of 
configuration  audits. 

5. 6. 1.3  Contractor  requirements. 

The  contractor  shall  be  responsible  for  establishing  the  time,  place,  and  agenda  for  each  configuration  audit  in 
consonance  with  the  master  milestone  schedule,  subject  to  coordination  with  the  Government.  This  should  be 
accomplished  sufficiently  in  advance  of  each  audit  to  allow  adequate  preparation  for  the  meeting  by  both  the 
contractor  and  the  Government:  In  addition,  the  contractor  shall: 

•  Insure  that  each  configuration  audit  schedule  is  compatible  with  the  availability  of  the  necessary 
information  and  contract  articles,  e.g.,  system  engineering  data,  trade  study  results,  producibility 
analysis  results,  risk  analysis  results,  specifications,  manuals,  drawings,  reports,  hardware,  software, 
firmware  or  mockups. 

•  Designate  a  co-chairperson  for  each  configuration  audit. 

•  Participating  contractor  and  subcontractor  personnel  or  those  chosen  to  make  presentations  shall  be 
prepared  to  discuss  in  technical  detail  any  of  the  presented  material  within  the  scope  of  the  audit. 

•  Provide  an  acceptable  method  to  record  inputs  to  official  meeting  minutes. 

•  Minutes  shall  be  recorded  and  shall  consist  of  significant  questions  and  answers,  action  items, 
deviations,  conclusions,  recommended  courses  of  action  resulting  from  presentations  or  discussions. 
Conclusions  from  discussions  conducted  during  side  meetings  shall  be  summarized  in  the  main 
meeting  at  an  appointed  time,  and  appropriate  comments  shall  be  read  into  the  official  minutes. 

•  Recommendations  not  accepted  should  also  be  recorded  together  with  the  reason  for  non-acceptance. 
The  minutes  of  each  daily  session  shall  be  available  for  review  by  both  the  contractor  and  Government 
personnel  at  the  beginning  of  the  next  day’s  session.  The  minutes  of  the  overall  audit  shall  be  available 
for  review  by  the  Government  prior  to  the  departure  of  the  audit  team  from  the  audit  location.  Official 
acknowledgement  by  the  Government  of  the  accomplishment  of  the  audit  shall  not  be  interpreted  as 
approval  of  statements  made  in  the  minutes  or  of  matters  discussed  at  the  audit  and  does  not  relieve  the 
contractor  from  requirements  which  are  part  of  the  contract. 

•  Record  all  discrepancies  identified  by  the  audit  Team  (See  Figure  3a  -  3b  for  a  sample  Audit  Action 
Item  List)  and  process  each  one,  as  a  part  of  the  audit  activities,  until  it  is  closed  out  or  suitable 
residual  tasks,  including  identification  of  responsible  activities  and  suspense’s,  have  been  established 
which  will  lead  to  the  close  out  of  the  discrepancy/action  item.  Clearly  record  all  action  items  in  the 
minutes  and  identify  both  the  Government  and/or  contractor  action  required  for  each  action  item’s 
resolution. 

•  Publish  the  official  minutes. 

5.6. 1.4  Government  participation. 

The  Government  will: 

•  Provide  a  co-chairperson. 

•  Provide  to  the  contractor  prior  to  the  audit  the  name,  organization,  and  security  clearance  of  each 
participating  individual. 

•  Review  the  daily  minutes  and  ensure  that  they  reflect  all  significant  Government  inputs. 

•  Provide  formal  acknowledgement  to  the  contractor  of  the  accomplishment  and  results  of  each 
configuration  audit  after  receipt  of  configuration  audit  minutes.  The  Government  will  evaluate  the 
results  of  each  configuration  audit  in  accordance  with  the  following  identifiers: 
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Approval  —  to  indicate  that  the  audit  was  satisfactorily  completed. 

Contingent  approval  —  to  indicate  that  the  audit  is  not  considered  accomplished  until  the  satisfactory  completion 
of  resultant  action  items. 

Disapproval  —  to  indicate  that  the  audit  was  seriously  inadequate. 

5.6.2  Functional  Configuration  Audit  [FCA). 

A  Functional  Configuration  Audit  shall  be  conducted  for  each  configuration  for  which  a  separate  development 
or  requirements  specification  has  been  baselined,  except  as  otherwise  required  by  contract,  and  for  the  overall 
system,  if  required  by  the  contract.  The  objective  of  the  FCA  shall  be  to  verify  the  configuration  item’s  and 
system’s  performance  against  its  approved  configuration  documentation.  Test  data  for  the  FCA  be  that  collected 
from  the  test  of  the  configuration  of  the  item  that  is  to  be  formally  accepted  or  released  for  production  prototype 
or  preproduction  article).  If  a  prototype  or  preproduction  article  is  not  produced,  the  test  data  shall  be  that 
collected  from  test  of  the  first  production  article.  Subject  to  prior  Government  approval,  the  FCA  for  complex 
items  shall  be  conducted  in  increments.  In  such  cases,  a  final  FCA  may  be  conducted  to  ensure  that  all 
requirements  of  the  FCA  have  been  satisfied.  In  cases  where  item  verification  can  only  be  completely 
determined  after  system  integration  and  testing,  the  final  FCA  shall  be  conducted  using  the  results  of  these  tests. 
See  Figures  5.6.2-la  and  lb  Audit  Action  Item  List. 
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AUDIT  ACTION  ITEM  LIST  -  PART  I 
PROBLEM  IDENTIFICATION 


FCA  _  PCA 


CONTROL  NO. 


CONTRACTOR 


CONTRACT  NUMBER 


CAGE  CODE 


ACTION  ITEM  ORIGINATOR  ORGANIZATION  - 

NAME  _  _ 

PHONE  _ 

IDENTIFICATION  OF  ITEM  BEING  AUDITED 

CONFIGURATION  ITEM  NONMENCLATURE— - 

PART  NUMBER _  SERIAL  NUMBER 

SUBELEMENT  AFFECTED  - - 

CONTRACT  REQUIREMENT (SI  AFFECTED 

DOCUMENT  PAGE  PARAGRAPH 


NARRATIVE  DESCRIPTION  OF  PROBLEM 


ALTERNATIVE  APPROACH  (OPTIONAL) 


FORWARDED  BY:  GROUP  LDR  _  TEAM  LDR 

Figure  5.6.2-la  Sample  Audit  Action  Item  List 
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AUDIT  ACTION  ITEM  LIST  -  PART  II 


CONTROL  NO. 


SIGNATURE 


ORIGINATOR  AUDIT  TEAM 


GOVERNMENT 


CONTRACTOR 


Figure  5.6.2-lb.  Sample  Audit  Action  Item  List  (continued) 


5. 6.2.1  Contract  requirements. 

The  schedule  dates,  and  actual  accomplishment  dates  for  the  FCAs  shall  be  recorded  in  the  CSA  system.  The 
Cl,  or  system,  shall  not  be  audited  separately  without  prior  Government  approval  of  the  FBL  and  ABL  of  the 
Cl,  or  system,  involved.  In  addition,  the  contractor  shall  make  the  final  draft  copy  of  the  Cl  product 
specification  available  to  the  Government  for  review  prior  to  the  FCA,  as  specified  in  the  contract. 
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5.6.2.2  Contractor  responsibility. 

Prior  to  the  audit  date,  the  contractor  shall  provide  the  following  infonnation  to  the  Government: 

•  Contractor  representation. 

•  Identification  of  items  to  be  audited: 

-  Nomenclature. 

-  Specification  identification  number. 

-  Cl  identification. 

•  Current  listing  of  all  deviations/waivers  against  the  Cl,  either  requested  of  or  approved  by  the 
Government.  Status  of  test  programs  to  test  configuration  items  with  automatic  test  equipment  (when 
applicable) 

•  The  contractor  shall  provide  a  matrix  for  each  Cl  at  FCA  that  identifies  the  requirements  of  sections 
three  and  four  of  the  specifications;  includes  a  cross  reference  to  the  test  plan,  test  procedures,  and  test 
report,  results  of  demonstrations,  inspections,  and  analyses  for  each  requirement;  and  identifies  each 
deficiency  by  deficiency  report  number.  The  matrix  shall  be  made  a  part  of  the  FCA  minutes. 

•  The  contractor  shall  prepare  an  FCA  check  sheet  which  identifies  documents  to  be  audited  and  tasks  to 
be  accomplished  at  the  FCA  for  the  Cl.  A  sample  FCA  Checklist  is  shown  in  Figure  5. 6. 2. 3-1. 

5.6.2.3  Verification  procedures  and  requirements. 

•  The  contractor  shall  provide  the  FCA  team  with  a  briefing  for  each  Cl  being  audited  and  shall 
delineate  the  test  results  and  findings  for  each  CL  As  a  minimum,  the  discussion  shall  include  Cl 
requirements  that  were  not  met,  including  a  proposed  solution  to  each  item,  an  account  of  the  ECPs 
incorporated  and  tested  as  well  as  proposed,  and  a  general  presentation  of  the  entire  Cl  test  effort 
delineating  problem  areas  as  well  as  accomplishments.  The  audit  should  also  include: 

a.  The  contractor’s  test  procedures  and  results  shall  be  reviewed  for  compliance  with  specification 
requirements. 

b.  The  following  testing  information  shall  be  available  for  the  FCA  team: 

-  Test  plans,  specifications,  descriptions,  procedures,  and  reports  for  the  CL 

-  A  complete  list  of  successfully  accomplished  tests  during  which  pre-acceptance  data  was 
recorded. 

-  A  complete  list  of  successful  tests  if  detailed  test  data  are  not  recorded. 

-  A  complete  list  of  tests  required  by  the  test  requirements  but  not  yet  performed.  (To  be  performed 
as  a  system  or  subsystem  test.) 

-  Preproduction  test  results. 

•  An  audit  of  formal  test  plans,  specifications,  and  procedures  shall  be  made  and  compared  against  the 
official  test  data.  The  results  shall  be  checked  for  completeness  and  accuracy.  Deficiencies  shall  be 
documented  and  made  a  part  of  the  FCA  minutes.  Interface  requirements  and  the  testing  of  these 
requirements  shall  be  reviewed.  Completion  dates  for  all  discrepancies  shall  be  clearly  established  and 
documented. 

•  For  those  requirements  which  cannot  be  completely  verified  through  the  use  of  testing,  the  FCA  shall 
determine  whether  adequate  analyses  or  simulations  have  been  accomplished  and  whether  the  results 
of  the  analyses  or  simulations  are  sufficient  to  insure  that  the  Cl  meets  the  requirements  in  the 
specification.  All  ECPS  that  have  been  approved  shall  be  reviewed  to  ensure  that  they  have  been 
technically  incorporated  and  verified. 

•  An  audit  of  the  test  reports  shall  be  performed  to  validate  that  the  reports  are  accurate  and  completely 
describe  the  Cl  tests.  Test  reports,  procedures,  and  data  used  by  the  FCA  team  shall  be  made  a  matter 
of  record  in  the  FCA  minutes. 

•  A  list  of  the  contractor’s  internal  configuration  documentation  of  the  HWCI  shall  be  reviewed  to  insure 
that  the  contractor  has  documented  the  physical  configuration  of  the  HWCI  for  which  the  test  data  are 
verified. 

•  Drawings  of  the  Cl  parts  which  are  to  be  provisioned  shall  be  selectively  sampled  to  assure  that  test 
data  essential  to  manufacturing  are  included  on,  or  furnished  with,  the  drawings. 

•  CIS  which  fail  to  pass  quality  requirements  are  to  be  analyzed  as  to  the  cause  of  failure  to  pass. 
Appropriate  corrections  shall  be  made  before  a  Cl  is  subjected  to  a  re -verification. 

•  Acknowledge  accomplishment  of  partial  completion  of  the  FCA  for  those  CIS  whose  verification  is 
contingent  upon  completion  of  integrated  system  testing. 
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FCA  CHECKLIST 


NOMENCLATURE  _ 

Cl  IDENTIFIER  _  DATE  _ 

CONTRACTOR  REQUIREMENTS  YES  NO 

1.  Deviation  List  Prepared  _  _ 

2.  Verification  Test  Procedures  Submitted  _  _ 

3.  Verification  Testing  Completed  _____  _ 

4.  Verification  Test  Results  Compiled  ( 

Available 

5.  Facilities  for  Conducting  FCA  Available 

6.  Verification  Test  Procedures  Reviewed 
and  Approved 

7.  verification  Testing  Witnessed 

8.  Verification  Test  Data  and  Results 
Reviewed  and  Approved 


COMMENTS 


Figure  5.6.2.3-1  Sample  FCA  Checklist 


•  For  CSCIs  the  following  additional  requirements  shall  apply: 

-  Review  data  base  characteristics,  storage  allocation  data  and  timing,  and  sequencing 
characteristics  for  compliance  with  specified  requirements. 
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-  Review  all  documents  which  comprise  or  describe  the  contents  or  the  use  of  the  software  product 
for  format  and  completeness,  (e.g.,  SPS,  User’s  Manual,  VDD) 

-  Review  the  records  that  reflect  the  changes  made  to  the  developmental  configuration  for  the  CSCI. 

-  Review  the  listing  of  all  versions  of  the  developmental  and  non-developmental  software,  firmware 
for  the  CSCIS  that  are  in  the  software  library. 

-  Review  the  findings  of  all  internal  CM  and  software,  firmware  QA  audits  of  the  CSCI. 

-  Preliminary  and  Critical  Design  Review  (CDR)  minutes  shall  be  examined  to  ensure  that  all 
findings  have  been  incorporated,  completed  and  all  action  items  are  closed. 

5. 6.2.4  Post-audit  actions. 

After  the  FCA  is  completed,  contractor  shall: 

•  a.  Publish  copies  of  the  FCA  minutes. 

•  b.  Record  the  accomplishment  and  results  of  the  FCA  in  the  CSA  Record  for  each  Cl  audited. 

•  c.  Accomplish  residual  tasks  for  which  they  were  identified  as  the  responsible  activity. 

5. 6.2. 5  FCA  Certifications. 

A  sample  FCA  certification  package  is  shown  in  Figures  5.6.3-la  through  5.6.3-lg.  When  specified  in  the 
contract,  a  Configuration  Audit  Summary  Report,  consisting  of  the  applicable  information  of  the  certification 
package  shall  be  required.  (See  6.3) 

5.6.3  Physical  Configuration  Audit  (PCA). 

The  PCA  shall  be  conducted  on  the  first  production  unit.  The  PCA  shall  be  formal  examination  of  the  as-built 
configuration  of  a  Cl  against  its  design  documentation.  The  PCA  can  be  conducted  on  down  stream  SRUs  if  the 
as  designed  is  same  as  first  production  unit.  The  PCA  for  a  Cl  shall  not  be  started  unless  the  FCA  for  the  Cl  has 
already  been  accomplished  or  is  being  accomplished  concurrent  with  the  PCA.  After  successful  completion  of 
the  audit  and  the  establishment  of  a  PBL  all  subsequent  changes  are  processed  by  formal  engineering  change 
action.  The  PCA  also  determines  that  the  acceptance  testing  requirements  prescribed  by  the  documentation  is 
adequate  for  acceptance  of  production  units  of  a  Cl  by  quality  assurance  activities.  The  PCA  includes  a  detailed 
audit  of  engineering  drawings,  specifications,  technical  data,  tests  utilized  in  production  of  CIS,  and  design 
documentation,  listings,  and  operation  and  support  documents  for  CSCIS.  The  PCA  shall  include  audit  of  the 
released  engineering  documentation  and  quality  control  records  to  make  sure  the  as-built  or  as-coded 
configuration  is  reflected  by  this  documentation.  For  software,  firmware  the  product  specification.  Interface 
Design  Document,  and  VDD  shall  be  a  part  of  the  PCA. 

•  The  PCA  shall  be  conducted  on  a  unit  of  the  item  selected  jointly  by  the  Government  and  the 
contractor. 

•  Satisfactory  completion  of  a  PCA  and  approval  of  the  product  specification  are  necessary  for  the 
Government  to  establish  the  PBL  for  a  CL 
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for 


Cl  IDENTIFIER (S) 


CONTRACT  NO. 


PRIME  CONTRACTOR: 


EQUIPMENT  MANUFACTURERS 


APPROVED  BY 


(CONTRACTOR) 


APPROVED  BY 


(GOVERNMENT) 


Figure  5.6.3-la.  Sample  FCA  Certification  Package 
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SCOPE: 


SC OPE /PURPOSE 


Functional  Configuration  Audit  (FCA)  was  conducted  on  the  following 
Configuration  Item: 

Cl  Identifier  Nomenclature  Pa  XL  fiO.  Seiial  Mfl 


purpose •  The  purpose  of  this  FCA  was  to  verify  that  the  configuration  item's 
performance  complied  with  the  Development  Specification. 


Figure  5.6.3-lb.  Sample  FCA  Certification  Package  (Continued) 
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(For  Equipment /Computer  Software) 


Contract : - 

Contractor :  _ 

Cl  Identifier: 


verification  Test  Procedures  and  Results,  The  verification  test/analysis 
results  have  been  reviewed  to  ensure  that  testing  is  adequate,  properly 
done,  and  certified.  (All  test  procedures  and  interface  documents  shall  be 
reviewed  to  assure  that  the  documents  have  been  approved  by  the  Government. 
All  test  data  sheets  shall  be  reviewed  to  assure  that  the  test  was  witnessed 
by  a  representative  of  the  Government.) 


Attached  is  a  list  of  the  documents  reviewed. 


Check  One 

□Procedures  and  results  reviewed  satisfy  the  requirements  and 
are  accepted.  See  Attachment  _  for  comments. 


I  I  Attached  is  a  list  of  deficiencies. 


Signature (s)  of  FCA  Team  Member (s) 


*  Sub-Team  Chairperson 
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FCA  CERTIFICATION  SHEET  NQ.  2 

(For  Equipment /Computer  Software) 

Contract : _ _ . _  Date: - 

Contractor:  _ _ 

Cl  Identifier:  — - - - 

Review  nf  npviarlnn<;  .  A  review  of  all  deviations  to  military 
specifications  and  standards  that  have  been  approved.  The  purpose 
is  to  determine  the  extent  to  which  the  equipment (s) /computer  software 
undergoing  FCA  vary  from  one  application  specifications  and  standards  and 
to  form  a  basis  for  satisfactory  compliance  with  these  specifications  ana 
standards.  In  accordance  with  this  paragraph,  all  applicable  deviations 
have  been  reviewed  with  the  following  results: 


Check  One 

□  The  equipment (s) /computer  software  listed  on  Certification  Sheet 
No.  1  of  this  report  complies  with  all  applicable  specifications 
and  standards.  See  Attachment  _  for  comments. 


□  Attached  is  a  summary  of  FCA  discrepancies. 
Signature (s)  of  FCA  Team  Member (s) 


*  Sub- Team  Chairperson 

A.  Deviation  Review  Team  Instructions.  All  approved  deviations  to 
military  specifications  and  standards  shall  be  reviewed  and 
recorded.  Also,  record  any  part  of  the  FCA  which  fails  to  meet 
specifications  or  standards  but  is  not  an  approved  deviation. 

B.  Results  Of  Team  Review.  List  the  deviations  against  the 
equipment /computer  software  being  FCA'd  that  were  reviewed. 


Figure  5.6.3-ld.  Sample  FCA  Certification  Package  (Continued) 
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Figure  5.6.3-le.  Sample  FCA  Certification  Package  (Continued) 


Configuration  Item  Nomenclature 

Specification  No. _ 

Test  Procedures - 


Figure  5.6.3-lf.  Sample  FCA  Certification  Package  (Continued) 
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Figure  5.6.3-lg  Sample  FCA  Certification  Package  (Continued) 


DEVIATIONS 

CONFIGURATION  ITEM  NOMENCLATURE: - — 


REFERENCE 
(Spec,  STD,  Etc.) 

CCD  OR  MRB 
APPROVAL/DIRECTIVE 

REQUIREMENT 

WAIVED 

REMARKS 

5. 6.3.1  Contract  requirements. 

The  schedule  dates,  and  actual  accomplishment  dates,  for  the  PCAs  shall  be  recorded  in  the  CSA  system.  All 
internally,  and  Government,  approved  engineering  changes  shall  be  incorporated  into  new  revisions  of  the 
applicable  configuration  documentation  prior  to  the  PCA.  In  addition,  the  contractor  shall  make  the  final  draft 
copy  of  the  product  specification  available  to  the  Government  for  review  prior  to  the  PCA,  as  specified  in  the 
contract. 

5. 6.3.2  Contractor  responsibility. 

Prior  to  the  audit  date,  the  contractor  shall  provide  the  following  information  to  the  Government: 

•  Contractor  representation. 

•  Identification  of  items  to  be  audited  by: 

(1)  Nomenclature. 

(2)  Specification  Identification  Number. 

(3)  Cl  Identifiers. 

(4)  Serial  Numbers. 

(5)  Drawing  and  Part  Numbers. 

(6)  CAGE  Codes. 

•  A  list  delineating  all  deviations  against  the  Cl  either  requested  or  Government  approved. 

•  Reference  information  to  the  Cl  being  audited  as  follows: 

(1)  Cl  product  specification. 

(2)  A  list  delineating  both  approved  and  outstanding  changes  against  the  CL 

(3)  Complete  shortage  list. 

(4)  Acceptance  test  procedures  and  associated  test  data. 

(5)  Engineering  drawing  index  including  revision  letters. 

(6)  Operating  and  support  manuals;  including  operators  manuals,  maintenance  manuals,  illustrated 
parts  breakdown,  programmer’s  manuals,  diagnostic  manuals,  etc. 

(7)  Proposed  DD  Form  250,  “Material  Inspection  and  Receiving  Report.” 

(8)  Approved  nomenclature  and  nameplates. 

(9)  VDDS,  for  software. 

(10)  FCA  minutes  for  each  CL 

(11)  Findings/Status  of  Quality  Assurance  Programs. 

(12)  Program  parts  selection  list. 

(13)  Interface  Design  Document  for  software. 

•  Assemble  and  make  available  to  the  PCA  team  at  time  of  audit  all  data  describing  the  item 
configuration,  to  include: 

(1)  Current  approved  issue  of  hardware  development  and  software  and  interface  requirements 
specifications  to  include  approved  SCNs  and  approved  deviations. 

(2)  Identification  of  all  changes  actually  made  during  test. 

(3)  Identification  of  all  required  changes  not  completed. 

(4)  All  configuration  documentation,  or  electronic  representations  of  the  same,  required  to  identify  the 
CL 

(5)  Manufacturing  instructions,  manufacturing  instruction  sheets  or  computer-aided  manufacturing 
(CAM)  data  related  to  drawings  and  computer-aided  design  (CAD)  presentations  of  specified  parts 
identified  by  the  Government. 

•  Identify  any  difference  between  the  physical  configurations  of  the  selected  production  unit  and  the 
development  unit(s)  used  for  the  FCA  and  shall  certify  or  demonstrate  to  the  Government  that  these 
differences  do  not  degrade  the  functional  characteristics  of  the  selected  units. 

•  A  sample  PCA  Checklist  is  shown  in  Figure  5. 6. 3. 3-1. 
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5. 6.3.3  PCA  procedures  and  requirements. 

The  following  actions  shall  be  performed  as  part  of  each  PCA: 

•  A  representative  number  of  drawings  (and/or  CAD  presentations)  and  associated  manufacturing 
instruction  sheets  (and/or  CAM  data)  for  each  item  of  hardware,  identified  by  the  Government  co¬ 
chairperson,  shall  be  reviewed  to  determine  their  accuracy  and  insure  that  they  include  the  authorized 
changes  reflected  in  the  engineering  drawings  (and/or  CAD  presentations)  and  the  hardware.  Unless 
otherwise  directed  by  the  Government  co-chairperson,  inspection  of  drawings  (and/or  CAD 
presentations)  and  associated  manufacturing  instructions  (and/or  CAM  data)  may  be  accomplished  on 
a  valid  sampling  basis.  The  purpose  of  this  review  is  to  insure  that  the  manufacturing  instructions 
(and/or  CAM  data)  accurately  reflect  all  design  details  contained  in  the  drawings  (and/or  CAD 
presentations)  .  Since  the  hardware  is  built  in  accordance  with  the  manufacturing  instructions  (and/or 
CAM  data),  any  discrepancies  between  the  manufacturing  instructions  (and/or  CAM  data)  and  the 
design  details  and  changes  in  the  drawings  (and/or  CAD  presentations)  will  he  reflected  in  the 
hardware.  The  following  hardware/computer  software  documentation  shall  be  available,  and  the 
following  tasks  shall  be  accomplished  at  the  pca. 
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PCA  CHF.rKT.T9T 


Th«  following  hardware,  computer  software,  documentation  shall  b«  aval labia 
following  tasks  shall  bo  accomplished  at  tho  PCA. 


and  tho 


HaidMaifi: 

Cflffiputec  Software.; 

Documantat 1  on : 

(1)  Approved  final  draft  of  the  configuration  item  product  specification. 

(2)  A  list  delineating  both  approved  and  outstanding  changes  against  the 
configuration  item. 

13)  Complete  shortage  list. 

M)  Acceptance  test  procedures  and  associated  test  data. 

(5)  Engineering  Drawing  Index. 

<&)  Operating,  maintenance,  and  illustrated  parts  breakdown  manuals. 

IT)  list  of  approved  material  review  board  actions  on  deviations. 

H)  Proposed  DC  Form  750.  "Material  Inspection  and  Receiving  Report." 

(*)  Approved  nomenclature  and  nameplates. 

(10)  Manuscript  copy  of  all  software  Cl  manuals. 

(Ill  Computer  Software  Version  Description  Document. 

(1?)  Current  set  of  listings  and  updated  design  descriptions  or  other  means 
of  design  portrayal  for  each  software  Cl. 

(13)  FCA  minutes  for  each  configuration  item. 

(14)  Program  Parts  Selection  List  (PPSL)  (see  MIL-STD-965) . 

lajiai 

(11  Define  Product  Baseline. 

(7)  Specification  Review  and  Validation. 

(3)  Drawing  Review. 

Ml  Review  acceptance  test  procedures  and  results. 

(5)  Review  shortages  and  unincorporated  design  changes. 

(*)  Review  deviations. 

(3)  Examine  proposed  DD  250. 

(*)  Review  contractor*  s  Engineering  Release  and  Change  Control 
System. 

(9)  Review  system  allocation  document. 

110)  Review  Software  User's  Manuals.  Software  Programmer's  Manuals. 

Computer  System  Operator's  Manual,  and  Firmware  Support  Manual. 

(11)  Review  software  CIs  for  the  following: 

(a)  Preliminary  and  detail  Software  Component  design  descriptions, 
lb)  Preliminary  and  detail  Software  interface  requirements. 

(e)  Data  base  characteristics,  storage  allocation  charts  and  timing 
and  sequencing  characteristics. 

(12)  Review  packaging  plan  and  requirements. 

(13)  Review  status  of  Rights  In  Data. 

114)  Ensure  that  all  appropriate  Items  installed  In  the  deliverable 
hardware,  that  should  have  been  processed  through  the  PCP.  are 
identified  on  the  PPSL  or  that  the  necessary  approval  documentation 
Is  aval 11  able  and  that  the  hardware  does  not  contain  Items  that  should 
have  been  processed  through  the  PCP  but  were  not  (see  MIL-STD-9S5) . 


YES 


NO 


Figure  5.6.3.3-1.  Sample  PCA  Checklist 
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•  The  following  minimum  information  shall  be  recorded  in  the  minutes  for  each  drawing  (and/or  CAD 
presentation)  reviewed: 

(1)  Drawing  number/title  (include  revision  letter). 

(2)  List  of  manufacturing  instructions  and/or  CAM  data  (numbers  with  change  letter/titles)  associated 
with  this  drawing. 

(3)  Discrepancies/comments. 

(4)  A  sample  of  part  numbers  reflected  on  the  drawing.  Check  to  insure  compatibility  with  the 
Program  Parts  Selection  List,  and  examine  the  Cl  to  insure  that  the  proper  parts  are  actually  installed. 

•  Asa  minimum,  the  following  inspections  shall  be  accomplished  for  selected  drawings  (and/or  CAD 
presentations)  and  associated  manufacturing  instructions  (and/or  CAM  data): 

(1)  Drawing  number  identified  on  manufacturing  instructions  (and/or  CAM  data)  shall  match  the  latest 
released  drawing  (and/or  CAD  presentation). 

(2) List  of  materials  on  manufacturing  instructions  (and/or  CAM  data)  shall  match  materials  identified 
on  the  drawing  (and/or  CAD  presentations). 

(3)  Nomenclature  descriptions,  part  numbers  and  serial  number  markings  called  out  on  the  drawing 
(and/or  CAD  presentation)  shall  be  identified  on  the  manufacturing  instructions  (and/or  CAM  data). 

(4)  Drawings  (and/or  CAD  presentations)  and  associated  manufacturing  instructions  (and/or  CAM 
data)  shall  be  reviewed  to  ascertain  that  all  approved  changes  have  been  incorporated  into  the  CI. 

(5)  Release  records  shall  be  checked  to  insure  all  drawings  (and/or  CAD  presentations)  reviewed  are 
identified. 

(6)  The  number  of  any  drawings  (and/or  CAD  presentations)  containing  more  than  five  outstanding 
changes  attached  to  the  drawing  shall  be  recorded. 

(7)  The  drawings  (and/or  cm  presentations)  of  a  major  assembly/black  box  of  the  HWCI  shall  be 
checked  for  continuity  from  top  drawing  down  to  piece -part  drawing. 

(8)  Insure  that  approvals  by  the  Government  are  present  where  required. 

•  The  Program  Parts  Selection  List  (PPSL)  shall  be  compared  to  the  HWCI/engineering  drawing 
package  to  ensure  only  approved  parts  are  listed.  (See  6.6) 

•  Review  of  all  records  of  baseline  configuration  for  the  by  direct  comparison  with  the  contractor’s 
engineering  release  system  and  change  control  procedures  to  verify  that  the  configuration  being 
produced  accurately  reflects  released  engineering  data.  This  includes  interim  releases  of  spares/repair 
parts  provisioned  prior  to  PCA  to  ensure  delivery  of  currently  configured  spares/repair  parts. 

•  Audit  the  software  library,  or  similar  internal  support  activity,  to  assure  that  it  accurately  identifies, 
controls,  and  tracks  changes  to  the  software  and  documentation.  Audit  the  contractor’s  engineering 
release  and  change  control  system  against  the  requirements  Appendix  B  to  ascertain  that  the  system  is 
adequate  properly  control  the  processing  and  formal  release  engineering  changes.  The  contractor’s 
system  shall  meet  the  information  and  capabilities  requirements  of  Appendix  B  as  a  minimum.  The 
contractor’s  formats,  systems,  and  procedures  will  be  used. 

•  CI  acceptance  test  data  and  procedures  shall  comply  with  product  specifications.  The  PCA  team  shall 
determine  any  acceptance  tests  to  be  re-accomplished,  and  reserves  the  right  to  have  representatives  of 
the  Government  witness  all  or  any  portion  of  the  required  audits,  inspections,  tests. 

•  CIs  which  fail  to  pass  acceptance  testing  shall  be  repaired  if  necessary  and  shall  be  retested  by  the 
contractor  either  in  the  manner  specified  by  the  PCA  team  leader  or  accordance  with  procedures  in  the 
product  specification. 

•  Present  data  confirming  the  inspection  and  test  of  subcontractor  equipment  end  items  at  point  of 
manufacture.  Inspection  and  tests  shall  have  been  witnessed  by  a  Government  representative. 

•  The  PCA  team  shall  review  the  prepared  back-up  data  (all  initial  documentation  which  accompanies 
the  CI)  for  correct  types  and  quantities  to  ensure  adequate  coverage  at  the  time  of  shipment  to  the  user. 

•  CIS  which  have  demonstrated  compliance  with  the  product  specification  will  be  approved  for 
acceptance.  The  PCA  team  shall  certify  by  signature  that  the  CI  has  been  built  in  accordance  with  the 
drawings  and  specifications. 

•  Asa  minimum,  the  following  actions  shall  be  performed  by  the  PCA  team  on  each  CSCI  being  audited: 

(1)  Review  all  documents  which  will  comprise  the  product  specification  for  format  and  completeness. 

(2)  Review  FCA  minutes  for  recorded  discrepancies  and  actions  taken. 

(3)  Review  the  design  descriptions  for  proper  entries,  symbols,  labels,  tags,  references,  and  data 
descriptions. 
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(4)  Compare  detailed  design  descriptions  with  the  software  listings  for  accuracy  and  completeness. 

(5)  Examine  actual  CSCI  delivery  media  (disks,  tapes,  etc.)  to  ensure  conformance  with  Section  5  of 
the  software  requirements  specifications. 

(6)  Review  the  annotated  listings  for  compliance  with  approved  coding  standards. 

(7)  Review  all  required  operation  and  support  documents  for  completeness,  correctness,  incorporation 
of  comments  made  at  Test  Readiness  Review  (TRR),  and  adequacy  to  operate  and  support  the 
CSCI(s).  Formal  verification  or  acceptance  of  these  manuals  should  be  withheld  until  system  testing  to 
ensure  that  the  procedural  contents  are  correct. 

(8)  Examine  the  related  documentation  to  ensure  that  the  relationship  of  the  CSCI  to  the  parts, 
components  or  assemblies  that  store  the  executable  forms  of  the  CSCI  is  properly  described.  For 
firmware,  ensure  that  the  information  completely  describes  the  requirements  for  installation  of  the 
CSCI  into  the  programmable  parts  or  assemblies  and  that  this  information  describes  the  requirements 
for  verification  that  the  installation  has  been  properly  implemented.  Where  follow-on  acquisition  of  the 
firmware  items  Is  intended,  ensure  that  the  documentation  has  been  accomplished  to  the  level  of  detail 
necessary  for  the  intended  reprocurement. 

(9)  Demonstrate,  using  deliverable  or  Government  owned  support  software,  that  each  CSCI  can  be 
regenerated.  The  regenerated  CSCI  shall  be  compared  to  the  actual  CSCI  delivery  media  to  insure  they 
are  identical. 

5.6.3.4  Post-audit  action. 

•  The  contractor  will  be  notified  in  writing  by  the  Government  of  acceptance  or  rejection  of  the  PCA,  of 
PCA  status  and  discrepancies  to  be  corrected,  or  rejection  of  the  PCA  and  requirements  for  re¬ 
accomplishment. 

•  After  completion  of  the  PCA,  the  contractor  shall  publish  and  distribute  copies  of  PCA  minutes  as 
specified  in  the  contract.  The  results  of  the  PPSL  review  will  be  included  in  the  final  PCA  minutes. 

•  Accomplish  residual  tasks  for  which  they  were  identified  as  the  responsible  activity. 

5.6.3. 5  PCA  Certification 

A  sample  PCA  certification  package  is  shown  in  Figures  5. 6. 3. 5-1  through  5. 6. 3. 5-1 1.  When  specified  in  the 
contract  DD  Form  1423,  a  Configuration  Audit  Summary  Report,  consisting  of  the  applicable  information  of 
the  certification  package  shall  be  required. 
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PCA  CERTIFICATION  PACKAGE 


Cl  IDENTIFIER: 

CONTRACT  NO. 

PRIME  CONTRACTOR: 

EQUIPMENT  MANUFACTURERS: 

APPROVED  BY  (Designee) 
(CONTRACTOR) 

APPROVED  BY  (designee) 

(GOVERNMENT) 

DATE 

DATE 

Figure  5.6.3. 5-1  Sample  PCA  Certification  Package 
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SCOPE /PURPOSE 

Scope:  A  Physical  Configuration  Audit  (PCA)  was  conducted  on  the 
following  end  items  of  equipment /computer  software: 


Cl  IDENTIFIER  CT  NOMENCLATURE  PART  NUMBER  SERIAL  MQ.  USD 


Purpose .  The  purpose  of  the  PCA  was  to  ensure  accuracy  of  the  identifying 
documentation  and  to  establish  a  product  baseline. 

The  establishment  of  a  product  baseline  for  equipment /computer  software  is 
not  to  be  construed  as  meeting  Government  requirements  for  delivery  of  an 
operational  system  meeting  approved  acceptance  criteria. 

Definition  of  Terms 

COMMENT  -  A  note  explaining,  illustrating,  or  criticizing  the  meaning  of  a 
writing.  Items  of  this  nature  should  be  explored  by  the  conrtractor  and/or 
the  Government,  but  corrective  action  is  NOT  necessary  to  successfully 
accomplish  the  PCA. 

DISCREPANCY  -  A  note  explaining,  illustrating,  or  criticizing  the  difference 
between  writings.  A  note  showing  the  variance  between  what  exists  and  what 
is  acceptable.  Items  of  this  nature  shall  be  rectified  by  the  contractor 
prior  to  successful  accomplishment  of  a  PCA. 


Figure  5. 6.3. 5-2  Sample  PCA  Certification  Package  (Continued) 
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(Tor  Equipment /Computer  Software) 


Contract : 


Contractor : 


Prndurr  Baseline.  The  following  documents  of  the  issue  and  date  shown 
comprise  the  product  baseline  for  the  listed  equipment (s) /computer  software 


SPEC  NC. 


ASSEMBLY  TOP 
DRAWING  NO. 


ISSUE 


EQU I PMENT /COMPUTER 
SOFTWARE  NOMENCLATURE 


Signature (s)  of  PCA  Team  Member (s) 


Team  Chairperson 
Sub-Team  Chairperson 


Figure  5. 6. 3. 5-3  Sample  PCA  Certification  Package  (Continued) 
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PCA  CERTIFICATION  SHEET  NO.  2 
(For  Equipment /Computer  Software) 

Contract : _ Date: 

Contractor : 


Specif lcat Ion  Review  and  Validation.  Specifications  have  been  reviewed  and 
validated  to  assure  that  they  adequately  define  the  configuration  item  and 
the  necessary  testing,  mobility/transportability  and  packaging  requirements. 

Check  One 

□The  Product  Specifications  are  complete  and  adequately  define 
the  configuration  item.  They  shall,  therefore,  constitute  the 
product  baseline.  See  attachment  _  for  comments. 

□The  Product  Specifications  are  unacceptable.  See  attachment  _ 

for  a  list  of  discrepancies. 

Signature (s)  of  PCA  Team  Member (s) 


•*  Team  Chairperson  •  Sub-Team  Chairperson 

A.  Specification  Review  and  Validation  Instructions.  The  detailed 
specifications  listed  in  paragraph  B.  below  shall  be  reviewed  for 
compliance  with  the  applicable  requirements.  Each  specification  shall 
serve  as  the  basic  document  for  configuration  control  of  the  subject 
configuration  items.  The  information  contained  within  the  specifications 
shall  be  audited  at  the  PCA. 

B.  Review  and  Validation  Results. 

1.  Specifications  reviewed  and  validated: 

EQUIPMENT/COMPUTER 

SFIC  HQ.  PARI  NO.  UAH  SOFTWARE  NOMENCLATURE 


2.  Specifications  Reviewed  and  Disapproved: 
(Provide  attachment  for  causes.) 


EQUIPMENT/COMPUTER 

SEEC-BQ-  PARI.  NQ .  DAI£  SOFTWARE  NOMENCLATURE 


Figure  5.6.3.S-4  Sample  PCA  Certification  Package  (Continued) 
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(Equipment ) 


Contract  :  _ 

Contractor : 


Drawing  Review.  Drawings  have  been  compared  with  the  equipment  to  ensure 
that  the  latest  drawing  change  letter  has  been  Incorporated  into  the 
equipment,  that  part  numbers  agree  with  the  drawings,  and  that  the  drawings 
are  complete  and  accurately  describe  the  equipment. 

Check  One 

□The  drawings  are  complete  and  accurately  describe  the  equipment.  See 
attachment  for  comments. 


□The  drawings  are  compatible  with  the  applicable  contract 
Program  Parts  Selection  List  (PPSL)  . 


Attachment 


is  a  list  of  discrepancies. 


Signature (s)  of  PCA  Team  Member (s) 
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PCA  CERTIFICATION  SHEET  NO.  4 
(Equipment) 

Contract:  -  Da1 

Contractor : _ 


Arronfanro  T>.«;t  Procedures  and  Results.  The  acceptance  test  procedures  have 
been  reviewed  for  adequacy  and  the  acceptance  test  results  have  been  reviewed 
to  ensure  that  the  testing  has  been  properly  done  and  certified. 

Attachment  _  is  a  list  of  the  documents  reviewed. 

Check  One 

Procedures  and  results  reviewed  satisfy  the  requirements  and 
are  accepted.  See  attachment  _  for  comments. 

Attachment  _  is  a  list  of 

discrepancies. 

Signature (s)  of  PCA  Team  Member (s) 


*  Sub-Team  Chairperson 

A.  ArrAPfanrA  Tpst  Procedures.  The  following  acceptance  test  procedures 
were  reviewed  by  the  ATP  Sub-Team: 

DOCUMENT 

NTTMBF.R  DATE /REV  LIB  DOCUMENT  TITLE _  STATUE 


B.  Arpgptance  Test  Results.  The  following  acceptance  test  results 
documentation  were  reviewed  by  the  ATR  Sub- Team: 

DOCUMENT 

NUMBER  DATE /REV  LTR  DOCUMENT  TITLE -  STATUS 


□ 

□ 


Figure  5. 6.3. 5-6  Sample  PCA  Certification  Package  (Continued) 
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PCA  CERTIFICATION  SHEET  NC.  5 
(For  Equipment /Computer  Software) 


Contract : — 
Contractor : 


Bwioy  nf  Shortages  and  Dr,  i  nrorpo  rar  ed  Design  Changes.  The  shortages  and 
unincorporated  design  changes  listed  on  the  proposed  DD  Form  250  "Material 
Inspection  and  Receiving  Report,”  and  other  records  have  been  reviewed. 


Check  One 


□ 


There  are  no  shortages  or  unincorporated  design  changes. 


Attachment  _  is  a  list  of  shortages  and/or  unincorporated  design 

changes,  and  the  recommended  corrective  action  required. 


Signature <s)  of  PCA  Team  Member (s) 


*  Sub-Team  Chairperson 

A.  Review  nf  Shortages  and  Unincorporated  Design  Changes.  All  shortages  and 
unincorporated  design  changes  listed  on  the  proposed  DD  Form  250,  "Material 
Inspection  and  Receiving  Report,"  shall  be  reviewed  by  the  Government  or 
their  designated  representatives  for  a  determination  of  what  changes  should 
be  accomplished  in  the  field  and  what  changes  should  be  accomplished  at  the 
contractor's  facility.  The  Government  shall  also  determine  if  the  reported 
shortages  and  unincorporated  changes  are  complete. 

B.  Results .  List  the  shortages  and  unincorporated  design  changes  that  were 
reviewed  in  compliance  with  requirements,  including  the  agreed-to  corrective 
action. 


Figure  5. 6.3. 5-7  Sample  PCA  Certification  Package  (Continued) 
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(For  Equipment /Computer  Software) 


Contract : 


Contractor : 


Review  Devi  at  i  nns  .  A  review  of  all  deviat  ions  to  military  specifications 

and  standards  that  have  been  approved.  The  purpose  is  to  determine  the 
extent  to  which  the  equipment (s) /computer  software  undergoing  PCA  vary 
from  applicable  specifications  and  standards  and  to  form  a  basis  for 
satisfactory  compliance  with  these  specif ications  and  standards. 


Check  One 


The  equipment ( s ) /computer  software  listed  on  Certification  Sheet 
No.  1  of  this  report  complies  with  all  applicable  specifications 
and  standards.  See  attachment  _  for  comments. 


Attachment 
comments . 


is  a  list  of  discrepancies  and/or 


In  accordance  with  this  paragraph,  all  applicable  deviations 
have  been  reviewed  with  the  following  results: 

Signature  (s)  of  PCA  Team  Member (s) 


*  Sub-Team  Chairperson 

Deviation  Review  Team  Instructions .  All  approved  deviations  to 
military  specifications  and  standards  shall  be  reviewed  and  recorded. 
Also,  record  any  part  of  the  PCA  which  fails  to  meet  specifications  or 
standards  but  is  not  an  approved  deviation. 

Results  of  Team  Review.  List  the  deviations  against  the  equipment/ 
computer  software  being  PCA'd  that  were  reviewed 
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PCA  CERTIFICATION  SHEET  NO.  7 
(For  Equipment/Computer  Software) 

Contract:  _ _ Date: 

Contractor:  _ _ _ _ 


Examination  of  the  Proposed  DP  Form  25C.  The  DD  Form  250  has  been 
examined  to  ensure  that  it  adequately  defines  the  equipment/computer 
software  and  that  unaccomplished  tasks  are  included  as  deficiencies. 

Check  One 

□  The  DD  Form  250  adequately  defines  the  equipment /computer 
software  and  all  unaccomplished  tasks  are  included  as 
deficiencies . 

'  ]  Attachment  _  is  a  list  of  discrepancies  and/or  comments. 

Signature  (s)  of  PCA  Team  Member (s) 


*  Sub-Team  Chairperson 

A  r.vAm)  nation  of  Proposed  DD  Form  250.  The  proposed  DD  Form  250  shall 
be  examined  for  completeness  and  an  accurate  definition  of  the 
equipment /computer  software.  Unaccomplished  tasks,  shortages,  and 
certain  specified  discrepancies  uncovered  at  the  PCA  shall  be 
included  in  the  DD  Form  250.  If  the  equipment/computer  software  is 
to  be  shipped  from  the  plant,  the  Program  Office  representative  will 
recommend  to  the  Contract  Administrative  Office  that  the  DD  Form  250 
be  executed  in  accordance  with  the  terms  of  the  contract. 

B.  Results .  Include  a  statement  that  the  proposed  DD  Form  250  was 
examined  and  recommended. 


Figure  5. 6. 3. 5-9  Sample  PCA  Certification  Package  (Continued) 


59 


(For  Equipment/Computer  Software) 


Contract : 
Contractor : 


contractor's  engineering  release  system  and  change  control  procedures  have 
been  reviewed  to  ensure  that  they  are  adequate  to  properly  control  the 
processing  and  formal  release  of  engineering  changes. 


Check  One 

□  The  contractor's  engineering  release  system  and  change  control 

procedures  are  adequate  for  the  processing  and  formal  release  of 
engineering  changes.  See  attachment  _  for  comments. 

□  Attachment  _  is  a  list  of  deficiencies. 

Signature  (s)  of  PCA  Team  Member (s) 


Figure  5.6.3.5-10  Sample  PCA  Certification  Package  (Continued) 
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PCA  CERTIFICATION  SHEET  NO. 
(Equipment) 


Contract : 
Contractor : 


l .  Revise,  al  Logistics  Suppose,  flaa  Iqx.  £x&.-flpeiaLlonal  Suppose  •  The 

Logistics  Support  Plan  for  Pre-operational  Support  has  been  reviewed  to 
ensure  that  it  is  adequate  to  support  the  acquisition  phase  and  is  compatible 
with  the  operational  phase  maintenance  concept  and  support  requirements. 


Check  One 


□  The  contractor's  Logistic  Plan  for  pre-operational  support  will 
fulfill  the  acquisition  phase  requirements  and  is  compatible  with 
operational  phase  needs. 

□  Attachment  _  is  a  list  of  deficiencies. 


PCA .  Long  Lead  Time  items  released,  and  items  provisioned,  prior  to  PCA 
have  been  reviewed  to  ensure  that  obsolete  items  resulting  from  pre-PCA 
design  changes  are  purged  from  the  system.  Where  basic  items  may  be 
upgraded  by  rework  or  modification  these  actions  have  been  verified  as 
accomplished  or  in  process  based  upon  design  change  notice. 

Check  One 

□  Long  lead  time  items  and  provisioned  items  processed,  prior  to 
PCA,  are  all  of  current  configuration  at  time  of  PCA  or  are  in 


work . 

Attachment 


is  a  list  of  deficiencies. 


Signature  (s)  of  PCA  Team  Member (s) 


Sub-Team  Chairperson 
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6.0 


NOTES 


(This  section  contains  information  of  a  general  or  explanatory  nature  that  may  be  helpful,  but  is  not  mandatory). 

6.1  Intended  use. 

6.2  Tailoring  guidance  for  contractual  application. 

The  requirements  of  this  standard  must  be  tailored  for  application  to  programs  involving  items  of  various  levels 
of  complexity  in  various  phases  of  their  life  cycle.  Table  II  is  provided  to  help  you  decide  which  requirements 
from  sections  4  and  5  should  be  invoked  in  your  contract.  Table  III  is  provided  to  help  you  decide  which  status 
accounting  tasks,  from  Appendix  H,  should  be  invoked  in  your  contract.  These  tables  list  numbered  paragraphs 
and  subparagraphs  only.  Lettered  subparagraphs  are  considered  an  integral  part  of  the  numbered  paragraph  or 
subparagraph  to  which  they  are  attached,  and  they  are  invoked  with  the  numbered  paragraph  or  subparagraph 
automatically,  unless  specifically  stated  otherwise  in  the  tasking  statement  in  the  Statement  of  Work.  Where  the 
subparagraphs  listed  in  the  tables  are  normally  invoked  as  a  unit  by  citing  the  lead  paragraph,  the  subparagraphs 
are  listed,  but  no  tailoring  guidance  is  provided  for  the  individual  subparagraphs;  when  certain  subparagraphs 
will  need  to  be  tailored  out,  or  when  they  may  be  separately  tailored  into,  the  contract,  separate  tailoring 
guidance  is  provided  for  those  specific  subparagraphs. 

6.2.1  Use  of  Table  I. 

The  columns  are  arranged  to  identify  the  normal  application  in  the  Demonstration  and  Validation  (D/V),  the 
Engineering  and  Manufacturing  Development  (EMD),  the  production  and  Deployment  (PRD),  and  the 
Operation  and  Support  (OPS)  phases  of  the  life  cycle.  The  SMPL  (sample  wording)  column  provides  a 
recommendation  on  which  of  the  sample  tasking  wording  to  use  (by  reference  to  samples  A,  B,  or  C  in  6. 2. 1.2) 
and,  if  applicable,  to  the  blank  spaces  (e.g.,  [I]or  [2]  in  the  sample.  The  NOTE  column  contains  a  “pointer”  to  a 
specific  Note  (see  6.2. 1.3)  that  will  provide  further  guidance  in  tailoring  the  requirement. 

6.2. 1.1  Explanation  of  codes  . 

A  number  of  codes  are  used  in  Table  I  paragraphs  that  would  not  normally  be  invoked  to  indicate  the 
applicability  of  a  specific  requirement  to  a  specific  phase  of  the  program.  The  following  codes  are  used: 

•  N/A  -  This  code  is  used  to  designate  “title-only”  paragraphs  that  would  not  normally  be  invoked  to 
incorporate  all  subparagraphs  into  the  contract. 

•  ALL  -  This  code  indicates  that  the  requirement  is  almost  always  invoked  for  this  phase,  with  the 
understanding  that  there  may  be  a  few  exceptions. 

•  NO  -  This  code  indicates  that  the  requirement  is  almost  never  invoked  for  this  phase,  with  the 
understanding  that  there  may  be  a  few  exceptions. 

•  MOST  -  This  code  indicates  that  most  programs  would  invoke  this  requirement  in  their  contract  for 
this  phase. 

•  OPT  -  This  code  indicates  that  this  is  an  optional  requirement  for  this  phase.  Based  on  the  notes 
provided,  you  will  have  to  determine  whether  to  invoke  it  in  your  contract. 

•  FEW  -  This  code  indicates  that  this  is  an  optional  requirement  for  this  phase  but  that  only  a  few 
programs  may  want  to  utilize  it.  (Usually  this  relates  to  a  requirement  that  is  normally  invoked  in  a 
later  phase  of  the  program.) 

•  SLOT  -  This  code  indicates  that  this  requirement  is  one  of  a  group  of  “either/or”  requirements  that 
must  be  selected  if  the  lead  paragraph  is  invoked  for  that  phase;  normally,  only  one  of  the  group  should 
be  selected. 
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Table  6.2.1.1-la  Tailoring  guide  for  use  with  this  TOR 


PW  1 

PARAGRAPH  TITVf 

D/v 

5® 

PAD 

OPS 

wort 

SHPL 

4 

ALL 

ALL 

ALL 

ALL 

a 

BID 

4.1 

ALL 

ALL 

ALL 

ALL 

4.2 

Planning  j 

ALL 

ALL 

ALL 

ALL 

4.1 

ALL 

ALL 

ALL 

ALL 

f  i  -*•  r^  ll  -M  f1: 

4.3.1 

XU. 

ALL 

ALL 

ALL 

4.3.2 

HOST 

HOST 

HOST 

MOST 

b 

B(3i 

4.1.1 

OPT 

OPT 

OPT 

OPT 

b 

B(3> 

4  .4 

A IX 

ALL 

ALL 

ALL 

4.5 

ALL 

ALL 

ALL 

ALL 

4.4 

ALL 

ALL 

ALL 

ALL 

4.7 

ALL 

ALL 

OPT 

OPT 

c 

BI3) 

s 

DTTAILkD  RWOXltfMBrrS 

M/A 

M/A 

M/A 

M/A 

■ 

■ 

S.l 

Purpose 

M/A 

N/A 

M/A 

N/A 

5.2 

Contis  ngt  aMinistration 

M/A 

M/A 

M/A 

■ 

■ 

m  i 

s.i.i 

Contractor 'a  04  Plan 

MOST 

HOST 

OPT 

BOB 

(Invoke*  apprmdix  A] 

L&jS 

5.2.2 

Work  breakdown  structure 

MOST 

HOST 

MOST 

■ 

$.2.3 

Technical  review* 

ALL 

ALL 

MO 

H 

RH 

Conflg  identification 

M/A 

M/A 

M/A 

M/A 

1 

Purpose  of  eenflg  1  dent  if 

ALL 

ALL 

ALL 

C(l> 

Configuration  ltaa  selection 

ALL 

ALL 

OPT 

mtmm 

C(l) 

mm 

ALL 

ALL 

OPT 

OPT 

m 

Bill 

ALL 

ALL 

OPT 

OPT 

!*■  - 

|  ft  p 

MOOT 

on 

on 

1(31 

Kill 

MOST 

on 

OPT 

1(3) 

5.3.4 

Configuration  Baaelinee 

ALL 

ALL 

OPT 

OPT 

■ 

cm 

$.1.4.1 

Configuration  Baseline /con fig 

ALL 

ALL 

ALL 

1(1) 

docunentatlon 

5.3. 4. 1.1 

Punct  Conflg  Docunentatlon 

ALL 

ALL 

OPT 

1(3) 

$.1.4. 1.2 

Alloc  Conflg  Docunantation 

re* 

ALL 

OPT 

1(3) 

5.3. 4. 1.3 

Product  Conflg  Docunentatlon 

MO 

OPT 

ALL 

1(3) 

5.3.4  .2 

Maint  of  confis  docunentatlon 

MOST 

HOST 

MOST 

OPT 

wwm 

1(3) 

$.1.5 

Bgrg  ralaaae  and  correlation 

ALL 

ALL 

ALL 

cm 

of  Manufactured  products 

(Invoke*  APPRMDIX  B] 

C  (21 

5. 3. S.l 

Specif icatioo  release/appvl 

ALL 

ALL 

ALL 

cm 

$.1.5.2 

Raqta  for  Bngrg  Bel  Record* 

OPT 

OPT 

OPT 

k 

A(l) 

S.l. $.2.1 

Os*  of  Cngrg  Ml  Mcords 

OPT 

(Invoke*  APPRMDIX  Cl 

K 121 

5.1. 5. 2. 2 

Betabllah  conflg  baseline* 

OPT 

$.3. $.2.1 

Change* 

OPT 

S3. 5. 2. 4 

Consolidation  of  Multiple 

OPT 

chgs  into  »  single  ERA 
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Table  6.2.1.1-lb  Tailoring  guide  for  use  with  this  TOR  (continued) 


PW  1 

PARAGRAPH  TITLE 

P/V 

Sffi 

PRP 

OPS 

HOTS 

SMPL 

5  3  6 

Configuration  identifier* 

ALL 

ALL 

ALL 

I 

B(l) 

5.3.41 

CAGE  code 

ALL 

ALL 

ALL 

5.3 .*.2 

ALL 

ALL 

ALL 

5.3*3 

ALL 

ALL 

ALL 

53.6.4 

MOST 

MOST 

MOST 

f 

B  (3  ) 

5.3*5 

HOST 

MOST 

MOST 

f 

B(3) 

5  3.** 

PW 

ALL 

ALL 

ALL 

m 

5.3.66  1 

FEW 

OFT 

OPT 

OPT 

n 

B  (3 ) 

5.3.66.2 

FEW 

ALL 

ALL 

ALL 

■ 

5. 3. *7 

FEW 

MOST 

MOST 

o,  f 

Bill 

5. 3. 6. 7.1 

WO 

MOST 

MOST 

f 

B(J) 

5.3.67.2 

HO 

MOST 

MOST 

f 

B(3) 

5. 3. *.7. 3 

MO 

OPT 

OPT 

OPT 

BI3) 

5.3.7 

Interface  management 

M/A 

M/A 

N/A 

■ 

5.3.7.X 

Interface  reguireemnts 

ALL 

ALL 

OPT 

C(l) 

5.3.7  3 

Rgt*  for  an  lew 

FEW 

OFT 

OPT 

B  (1) 

5. 3. 7. 2.1 

ICMG  eeeberehip 

PBN 

OPT 

OPT 

H 

5. 3. 7. 2. 2 

IOC  chairmanship 

SLOT 

SLCT 

SLCT 

I 

IM 

B  (3 } 

5.* 

Configuration  control 

W/A 

H/A 

M/A 

M/A 

5.4 .1 

ALL 

ALL 

ALL 

ALL 

C(l) 

5.4.2 

Regta  for  engineering  Change* 

ALL 

ALL 

ALL 

ALL 

5. 4.2.1 

The  engrg  change  process 

ALL 

ALL 

ALL 

ALL 

C(l) 

5. 4. 2. 2 

Administrative  requirement* 

ALL 

ALL 

ALL 

ALL 

■ 

B(l) 

5. 4. 2. 2.1 

Claaaif ication  of  engrg  chga 

ALL 

ALL 

ALL 

ALL 

* 

5. 4.2. 3. 2 

Classifying  engrg  chg  to  FDI 

FBM 

OPT 

OPT 

OFT 

•  O) 

5. 4. 2. 2. 3 

Content  of  tCP* 

ALL 

ALL 

ALL 

ALL 

B(2> 

{Invoke*  APPX  D) 

54.22.3.1 

Unrelated  engrg  change* 

ALL 

ALL 

ALL 

ALL 

5.4  .2. 2. 3. 2 

Revlaion*  of  BCP* 

ALL 

ALL 

ALL 

ALL 

af 

B  (3) 

5.43.2.3.3 

Supporting  data 

ALL 

ALL 

ALL 

ALL 

5. 4. 2. 2. 3. 4 

Classified  data 

ALL 

ALL 

ALL 

ALL 

5. 4. 2. 3 

Claaa  I  engrg  chg  propoaala 

ALL 

ALL 

ALL 

ALL 

B(l) 

5. 4. 2. 3.1 

Ciaas  I  BCP  decision* 

M/A 

M/A 

N/A 

5. 4. 2. 3. 1.1 

Tgt  for  tach  decia-Cl*  I  BCP 

ALL 

ALL 

ALL 

5.4.2.31.2 

BCP  authorisation 

ALL 

ALL 

ALL 

ALL 

5. 4. 2. 3. 1.3 

Cla  I  coapat  engrg  chga 

ALL 

ALL 

ALL 

ALL 

5. «. 2. 3. 1.4 

Disapproval  of  BCPs 

ALL 

• 

ALL 

ALL 

ALL 

5. 4. 2. 3. 2 

Class  I  BCP  juatlf  codes 

ALL 

ALL 

ALL 

ALL 

• 

64 


Table  6.2.1.1-lc  Tailoring  guide  for  use  with  this  TOR  (continued) 


» 

PARAGRAPH  TITLE 

D/V 

D® 

PRD 

OPS 

HOTE 

5MPL 

$.4. 2. 1.3 

Class  1  ECP  types 

ALL 

ALL 

ALL 

ALL 

5. 4. 2. 3. 11 

Preliminary  change  proposal 

ALL 

ALL 

ALL 

ALL 

5.4.2.3.3.11 

Osc  of  preliat  ECPa  (Type  P) 

ALL 

ALL 

ALL 

ALL 

a 

B  ( 3) 

54.2.3.32 

Uae  of  formal  ECP  (Type  F) 

ALL 

ALL 

ALL 

ALL 

5.4.2.34 

Claaa  1  engrg  chg  priorities 

ALL 

ALL 

ALL 

ALL 

5. 4. 2. 3. 4.1 

Exped  Cla  I  ECPa  w/priority 

ALL 

ALL 

ALL 

ALL 

of  emergency  or  urgent 

$.4.23.5 

Poraet  for  Cla  I  engrg  chg* 

ALL 

ALL 

ALL 

ALL 

$.4. 2.1. 5.1 

Claaa  I  engrg  changes- functional 

ALL 

NO 

NO 

NO 

B  (3  J 

S.4.2.1.S.2 

Class  I  engrg  changes-allocated 

NO 

ALL 

m 

HO 

B  (3) 

$.4. 2. 3. S3 

Class  I  engrg  changes-prod  baseline 

NO 

wo 

B 

NO 

Bill 

S. 4.2.3* 

Related  engineering  changes 

ALL 

ALL 

ALL 

ALL 

$.4 .2.1*1 

Eel  engrg  chgs-single  priae 

wo 

ALL 

ALL 

ALL 

B(l) 

$.4. 2. 3. *.2 

Rel  engrg  chga -single  priae- 

OPT 

OPT 

OPT 

OPT 

t 

B  (3) 

eulti  procuring  activities 

$.4. 2. 3. (.3 

Rel  egrg  chga-aeparte  priaes 

OPT 

OPT 

OPT 

OPT 

t 

B  (3) 

$.4. 2. 3. (.4 

Saae  egrg  chga -pring/sub  coord 

OFT 

on 

art 

OPT 

t 

B(3) 

$.4.2.3.*.$ 

Sana  egrg  chg-sev  contractors 

on 

on 

OPT 

OPT 

t 

B  (3) 

5. 4. 2. 4 

Class  II  engineering  changes 

NO 

m 

ALL 

ALL 

u 

B(30 

5. 4. 2. 4.1 

Class  II  engrg  chg  format 

wo 

PIN 

ALL 

ALL 

5.4. 2. 4. 2 

Class  II  justification  codes 

NO 

nw 

ALL 

ALL 

S.4.2.4.3 

Concurrence  in  Class  II  chgs 

NO 

SLOT 

SLOT 

SLCT 

u 

B(3) 

$.4. 2. 4. 4 

Approval  of  Class  II  chgs 

NO 

SLOT 

SLOT 

SLCT 

u 

BO) 

$.4.2.4.$ 

Won-custody  of  original  dvgs 

NO 

wo 

OPT 

OPT 

BO) 

$.4.1 

• 

Reguireaents  for  Raguests 

B 

raw 

ALL 

ALL 

B 

A(X) 

for  Deviation  (REDS) 

S.4.3.1 

Restrictions  on  deviations 

$.4.3.2 

Recurring  deviations 

$.4.1.1 

Classification  of  deviations 

5. 4. 3. 3.1 

Minor 

H 

S.4.3.1. 2 

Major 

5.4.3 .3 .3 

Critical 

$.4.3.4 

ronaat 

B 

(Invoices  APPEJ4DIX  E) 

2171 

$.4.3.$ 

Disposition  of  deviations 

S.4.1.S.1 

Minor  deviations 

|  5. 4. 1.5. 2 

Critical  and  aajor  deviations 
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Table  6.2.1.1-ld  Tailoring  guide  for  use  with  this  TOR  (continued) 


PWU  t 

PARAGRAPH  TITLE 

D/V 

DC 

PAP 

OPS 

mm 

SMPL 

mm 

Part*  aubstitution 

KO 

NO 

ALL 

ALL 

i 

C(l) 

S.4.S 

1.4.5.1 

5.4.5.2 

Rqta  for  Spec  Change  Notices 
(SOU)  (Invokes  APPX  F) 

Approved  SOI 

Changed  pages 

ALL 

ALL 

ALL 

ALL 

% 

A(l) 

Ad) 

S.4.C 

Rqta  for  Notice  of  Revision 
(Meats)  (Invokes  APPX  G) 

■ 

■ 

■ 

CC1) 

Cd) 

66 


Table  6.2.1.1-le  Tailoring  guide  for  use  with  this  TOR  (continued) 


£££&_! 

PARAGRAPH  TITLE  j 

P/V  j 

EMD  | 

PEP 

OPS 

B 

SHPL  ! 

5.5 

Config  Status  Acctg  (CSA) 

OPT 

ALL 

ALL 

ALL 

AA 

»(1» 

s.s.i 

Purpose  of  CSA 

OPT 

ALL 

ALL 

ALL 

S  .  5 . 2 

CSA  requirements 

OPT 

ALL 

ALL 

ALL 

(Invokes  AFFCNDIX  X) 

5.5.3 

Preferred  Information  system 

OFT 

ALL 

ALL 

ALL 

5.S.4 

Retention  of  hlstor  database 

ALL 

ALL 

ALL 

ALL 

5.S.S 

CSA  data  elements 

OPT 

ALL 

ALL 

ALL 

(Invokes  APPBOIX  I) 

s.s.c 

Contractor  focal  point 

ALL 

ALL 

ALL 

ALL 

5.5.7 

res  analysis  requirements 

F*V 

rsv 

OPT 

OPT 

FmHIi 

5.S.* 

Reporting  sccomp  of  retro  chga 

NO 

MO 

OPT 

OFT 

HnBil 

(invokes  APPWDIX  J) 

5.C 

Configuration  audits 

N/A 

N/A 

N/A 

N/A 

1 

S.t.l 

MO 

ALL 

S. (. 1. 1 

|  ' 

5.C.1.2 

Location 

5. $.1.3 

5. (.1.4 

■ 

■  ■ 

5.C.2 

Functional  Coot  Audit  (FCA) 

NO 

ALL 

NO 

a 

MB 

A(l) 

S.C.2.1 

Contract  reqte 

5.C.2.2 

Contractor  responsibility 

5.4.2.J 

Vsrlf  procedures  and  rqts 

5 .( .2.4 
5.C.2.S 

Post -audit  actions 

FCA  Certification  Package 

- 

■ 

S.*.l 

Physical  Confg  Audit  (FCA) 

NO 

OPT 

OFT 

OFT 

A« 

Ad) 

S.t.3.1 

Contract  reqts 

S.C.1.2 

Contractor  responsibility 

S.t.J.3 

FCA  procedures  and  rqts 

S.C.1.4 

Post-audit  actions 

S.S.J.S 

PCX  Certification  Package 

6.2. 1.2  Sample  wording  for  contractual  tasking. 

6.2. 1.2.1  Invoking  a  complete  set  of  requirements. 

The  requirements  of  the  standard  are  arranged  so  that,  in  large  part,  they  can  be  invoked  by  reference  to  a  lead 
paragraph;  all  subparagraphs  of  that  lead  paragraph  are  then  applied  to  the  contract.  If  an  Appendix  other  than 
Appendix  H  (CSA)  is  invoked  within  the  paragraph,  it  is  intended  that  the  entire  Appendix  be  invoked,  and  the 
task  should  include  that  wording. 

SAMPLE  A:  The  contractor  shall  (ea.,  process  requests  for  deviation  from  the  current  approved  configuration 
documentation)  in  accordance  with  TOR,  paragraph  [1]  [e.g.,  5.4.3)  and  subparagraphs,  [NOTE:  if  an  Appendix 
is  invoked  by  the  paragraph,  include]  and  Appendix  [2]  (e.g.,  E). 


6.2. 1.2.2  Tailoring  out  specific  requirements. 

Some  of  the  requirements  of  this  standard  are  provided  for  use  in  specific  circumstances;  one  (or  more)  of  the 
subparagraphs  will  have  to  be  tailored  out  even  though  all  of  the  other  subparagraphs  under  the  lead  paragraph 
still  apply. 

SAMPLE  B:  The  contractor  shall  (eg.,  document  Class  II  engineering  changes)  in  accordance  with  this  TOR, 
paragraph  [1]  (e.g.,  5. 4. 2. 4)  and  subparagraphs,  [NOTE:  if  an  Appendix  is  invoked  by  the  paragraph  include] 
and  Appendix  [2]  (eg.  D) ,  except  that  subparagraph(s)  [3]  (e.g.,  5. 4. 2. 4. 4)  and  (3)  does  not  apply. 
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6. 2. 1.2.3  Identifying  specific  applicable  requirements. 

Other  requirements  in  this  standard  are  intended  to  be  invoked  by  themselves  as  we  select  specific  parts  of  a 
general  CM  tasking  for  a  particular  program.  If  an  Appendix  other  than  Appendix  H  (CSA)  is  invoked  within 
the  paragraph,  it  is  intended  that  the  entire  Appendix  be  invoked,  and  the  task  should  include  that  wording. 

SAMPLE  C:  The  contractor  shall  (  a.  g.  manage  the  interfaces  of  the  items  being  developed  in  accordance  with 
this  TOR,  paragraph(s)  [1]  (e.  g  .  .,  5.3.7. 1)  and  [1]  [  NOTE:  if  an  Appendix  is  invoked  by  the  paragraph, 
include]  and  Appendix  [21]. 

6. 2. 1.3  Specific  tailoring  notes. 

The  following  specific  tailoring  information  is  provided  to  supplement  the  guidance  provided  in  Table  II. 
[NOTE:  The  number  in  parentheses  at  the  beginning  of  each  note  is  the  number  of  the  primary  paragraph(s)  to 
which  it  applies.  ] 

a.  (4)  The  General  Requirements  of  a  standard  are  normally  invoked  on  all  contracts  without  tailoring. 
In  this  standard,  the  only  exceptions  are  for  the  electronic  transfer  of  data  (4.3.2),  for  the  interactive 
access  to  digital  data  (4.3.3),  and  for  the  audits  (4.7).  You  will  have  to  decide  whether  to  tailor  them 
out  for  your  program. 

b.  (4.3.2  and  4.3.3)  While  the  use  of  electronic  submittal  of  data  will  become  nearly  universal,  some 
programs  may  not  want  to  use  the  capabilities;  this  will  be  especially  true  in  the  next  few  years  while 
this  technology  is  maturing.  The  requirement  for  the  capability  to  interactively  access  the  contractor’s 
database  will  be  applied  only  to  selected  programs  where  such  access  to  “real-time”  data  is  necessary 
to  successfully  manage  the  program.  A  primary  criterion  will  be  the  size  of  the  contractor  and  the 
availability  of  a  database  in  the  contractor’s  organization  to  provide  the  needed  information.  For  a 
small  contractor,  on  a  small  program,  who  does  not  have  such  a  capability,  this  requirement  could 
vastly  increase  the  contract  cost. 

c.  (4.7)  This  paragraph  would  be  invoked  on  every  contract  which  invokes  the  detailed  FCA  (5.6.2)  or 
PCA  (5.6.3)  tasks  of  this  standard.  (See  also  6.2. 1.3. ad  and  se.) 

d.  (5.2.1)  CM  Plans  are  usually  required  as  a  part  of  the  first  phase  of  the  program,  with  updates 
provided  at  least  with  the  transition  to  the  next  phase  of  the  development.  The  CM  Plan  may  be  used  as 
a  guidance  document,  or  it  may  be  invoked  (by  referencing  the  number,  revision,  and  date)  as  a 
contractually  binding  requirement,  based  on  the  preference  of  the  program. 

e.  (5.3.3)  The  developmental  configuration  terminology  has  been  expanded  to  include  both 
developmental  hardware  and  software.  During  Demon  stration/V alidation  and  EMD  phases,  we  want 
the  contractor  to  internally  control  the  developmental  documentation  once  it  has  been  released  and 
prior  to  its  being  baselined  by  the  Government.  Once  into  the  Production  phase,  such  control  is  still 
required  for  changes  the  contractor  is  developing;  so  this  requirement  might  continue  to  be  invoked. 

f.  (53.3.2/5.3.3.3;  5.3.6.4/53.6-5;  53.6.7/53.6.7.1/  53.6.7.2)  Most  contracts  will  invoke  these 
paragraphs,  since  they  will  involve  the  development  and  production  of  both  hardware  and  software. 
When  a  contract  involves  strictly  one  or  the  other,  only  the  appropriate  paragraph(s)  should  be 
invoked.  Also,  when  it  is  desired  that  the  contractor  use  Government  issued  drawing  numbers  and/or 
part  numbers,  that  requirement  should  be  cited. 

g.  (53.4.1.1)  Many  major  systems  will  require  the  identification  of  the  FCD  in  the  Concept 
Exploration  phase  and  the  baselining  of  the  FCD  in  the  Demonstration/Validation  phase.  On  smaller 
programs  that  start  with  EMD  phase,  this  requirement  should  be  invoked  in  that  contract;  for  major 
systems,  the  requirement  for  compliance  with  the  FCD  should  be  continued  during  the  EMD  phase. 
Once  production  phase  is  reached,  many  programs  rely  only  on  the  PCD  for  definition  of  their 
requirements  for  the  items  they  are  buying.  Others  (mainly  larger  systems)  continue  to  invoke  the  FCD 
as  the  overall  requirement  for  the  capabilities  of  all  of  the  items  they  are  buying,  especially  for 
correction  of  deficiencies  determinations. 

h.  (53.4.1.2)  Most  programs  which  include  a  Demonstration/Validation  phase  will  include  the 
requirement  to  generate  the  draft  ACD  during  that  phase;  the  ABL  will  be  established  as  a  part  of  the 
EMD  tasking.  Once  the  Production  phase  is  reached,  many  programs  rely  only  on  the  PCD  for 
definition  of  their  requirements  for  the  items  they  are  buying.  Others  continue  to  invoke  the  ACD  as 
the  overall  requirement  for  the  capabilities  of  the  particular  item  they  are  buying,  especially  for 
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correction  of  deficiencies;  if  that  is  the  case,  MIL-STD-961  (program-unique)  specifications  for  the 
ACD  and  PCD  should  be  ordered  as  “two-part”  specifications. 

i.  (5.3.4. 1.3)  Most  programs  will  require  the  identification  of  the  PCD  during  the  EMD  phase. 

Programs  including  software  may  require  the  establishment  of  the  PBL  for  the  software  during  the 
EMD  phase.  Programs  which  plan  to  compete  the  production  contract  for  the  item(s)  being  developed 
should  require  the  establishment  of  the  PBL  as  a  part  of  the  EMD  effort.  All  other  programs  will 
normally  establish  the  PBL  as  a  part  of  the  Production  phase  effort. 

j.  (5.3.4. 1 .4)  Most  programs  will  require  the  contractor  to  maintain  the  original  copies  of  the 
configuration  documentation  during  the  Demonstration/V alidation  and  EMD  phases.  Many  programs 
continue  with  contractor  maintenance  of  the  originals  throughout  the  production  phase,  too;  some 
transfer  control  of  the  originals  to  the  program  office.  In  the  Operation  and  Support  phase,  the 
documentation  is  usually  maintained  by  the  managing  DOD  service. 

k.  (5. 3. 5. 2)  Once  the  government  has  taken  control  of  the  originals  of  the  configuration  documentation, 
it  may  require  that  the  activity  implementing  the  ECP  update  the  originals  and  release  them  using  a 
specific  form  called  an  Engineering  Release  Record  (ERR). 

l.  (5.3.6,  5. 3. 6. 7. 3)  Most  contracts  should  invoke  this  lead  paragraph  to  incoiporate  the  entire  section  of 
requirements  on  configuration  identifiers.  However,  the  paragraph  on  NDI/COTS/PDI  numbering 
should  be  tailored  out  unless  it  is  appropriate. 

m.  (5. 3. 6. 6. ,  5. 3. 6. 6. 2)  The  requirements  for  the  contractor  to  plan  for  (and  sometimes  start)  issuing 
serial  numbers  is  usually  invoked  for  the  EMD  phase.  The  continuing  requirement  for  the  issue  of  the 
serial  numbers  is  usually  invoked  in  the  production  contract(s) . 

n.  (5. 3. 6. 6.1)  For  some  specialized  types  of  equipment,  the  Government  issues  the  serial  numbers  to  be 
affixed  to  the  deliverable  units.  If  such  equipment  is  a  part  of  your  program,  this  requirement  must  be 
invoked  specifically  for  the  equipment  involved.  Also,  if  a  follow-on  production  or  spares  buy  is 
awarded  to  a  contractor  other  than  the  original  design  activity,  it  may  be  advantageous  to  invoke  this 
requirement  if  you  want  the  serial  numbers  for  the  delivered  units  to  continue  in  an  unbroken  string 
even  though  the  CAGE  changes. 

o.  (5.3.6.7)Product  marking  is  most  critical  during  the  production  and  support  phases  to  make  sure  that 
the  deliverable  units  are  adequately  identified.  However,  this  task  will  normally  be  invoked  in  the 
EMD  phase  to  require  the  contractor  to  establish  the  procedures  and  evaluate  the  medium  to  be  used  to 
accomplish  this  marking. 

p.  (5.3.7. 1)  Once  programs  reach  the  Production  phase,  control  of  interfaces  below  the  ACD  level  is 
provided  through  control  of  the  detail  design  invoked  in  the  product  baseline  and  the  PCD.  If  a  detail 
design  is  not  invoked  for  production,  then  this  requirement  is 

needed. 

q.  (5. 3. 7. 2)  The  Interface  Control  Working  Group  (ICWG)  is  required  primarily  when  the  Government 
has  awarded  several  contracts  to  different  contractors  for  the  development  of  different  pieces  of  a 
system.  It  may  also  be  utilized  where  several  different  DOD  agencies  services  must  meet  regularly 
with  one  or  more  contractors  developing  the  system.  If  an  ICWG  is  needed,  then  the  contractor’s  role 
as  either  a  member  or  as  the  chair/member  must  be  identified.  If  contractor  is  to  be  a  member,  invoke 
53.1 2  and  tailor  out  5. 3. 7. 2. 2;  if  contractor  is  to  be  the  ICWG  chair  and  a  member,  invoke  53.1.2 
using  Sample  A. 

r.  (5. 4. 2. 2.2)  If  privately  developed  items(NDI,  COTS,  PDI)  are  not  involved  in  the  program,  this 
requirement  should  not  be  invoked. 

s.  (5. 4. 2. 3. 3. 1.1  and  5. 4. 2. 3. 3. 1.2)  When  the  program  wants  to  obtain  brief  preliminary  information 
about  routine  Class  I  engineering  changes,  the  contract  must  specifically  cite  the  use  of  the  preliminary 
ECP  for  this  purpose, 

t.  (5. 4. 2. 3. 6. 3  -  5. 4.2. 3. 6. 5)  These  task  is  normally  not  required  during  the  Demonstration/Validation 
phase  since  the  allocated  baselines  would  not  be  established  until  the  end  of  this  phase  or  the  beginning 
of  the  EMD  phase;  thus,  there  would  be  no  related  ECPS.  These  task  would  only  be  invoked,  along 
with  the  requirement  for  the  “related  changes  for  a  single  prime”,  when  the  situation  cited  exists.  You 
will  have  to  evaluate  your  acquisition  strategy  to  determine  whether  they  will  apply. 

u.  (5. 4. 2. 4/5. 4. 2. 4. 3/5. 4. 2. 4  .4)  Since  Class  1 1  engineering  changes  apply  only  to  the  product  baseline, 
this  set  of  paragraphs  is  applicable  primarily  in  the  production  phase  and  beyond.  If  product  baselines 
will  be  established  as  a  part  of  the  EMD  phase,  then  this  task  would  be  invoked  for  use  once  the 
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PBL(s)  is  established.  The  contract  must  specify  that  either  “concurrence”  or  “approval”  of  the  Class  II 
changes  apply  by  citing  the  appropriate  subparagraph. 

v.  (5. 4. 2. 4. 5)  If  the  contractor  will  not  have  control  of  the  originals  of  the  “drawings”,  this  requirement 
should  be  invoked  to  define  the  requirement  for  Government  approval  of  the  Class  II  changes.  That 
practice  requires  considerable  manpower  to  monitor.  These  optional  Tasks  should  be  used  selectively; 
they  would  be  most  useful  in  situations  where  lack  of  supportability  for  the  system/item  can  have 
significant  National  Security  impacts  to  the  extent  that  such  detailed  information  is  necessary  to 
minimize  such  supportability  problems. 

w.  (H.5.1.5)  Configuration  of  units  in  the  field.  This  paragraph  and  Task  501  are  normally  invoked 
only  for  the  Production  phase  contract.  The  government  support  activity  usually  has  an  existing 
information  system  that  will  provide  the  information  required  for  Tasks  502  and  503.  If  SO,  it  should 
be  used  from  the  start  of  the  delivery  of  production  units  to  simplify  the  transition  from  a  contractor  to 
a  government  information  system  when  production  is  complete. 

x. (H.5.1.6)  Tracking  audit  action  items.  This  paragraph  and  Tasks  601  and  602  would  not  normally  be 
invoked  on  contracts.  The  government  buying  activity  normally  has  sufficient  resources  to  provide 
adequate  tracking  capabilities  and  retention  of  historical  information. 
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Table  6.2. 1.3-1  Application  of  CSA  Tasks 


LIFE  CYCLE  PHASE 

Of  MOiTntATIONA 
VAU0ATKX 

INCmIEMCI 

orvticptCMT 

HttoucnoN 
•  otncmctfT 

O0CAATO# 

4  MWT 

BASELINE(S)  NORMALLY  IN  EFFECT 

H*CTK**l 

lUCLMC 

PUNCTO**/ 

AUOCATCOMCiPC 

fuNcno 

MJLOCATfDf 

moouct  Msciwc 

'UMCTO*!/ 

AUOCATtDf 

MOOOCT 

TASK  101 

Speculation  Reunion  Level 

REOUIRED 

CONTRACTOR 

REOUIRED 

CONTRACTOR 

REOUIRED 

CONTRACTOR 

REOUIRED 
SUPPORT  activity 

TASK  102 

Specification  Revision  History 

REOUIRED 

CONTRACTOR 

REOUIRED 

CONTRACTOR 

REOUIRED 

CONTRACTOR 

REOUIRED 
SUPPORT  ACTIVITY 

TASK  103 

TASK  104 

TASK  105 

TASK  106 

Drawing  Revision  Level 

Drawing  Revision  History 

Software  Version  Level 

Software  Version  Hisiory 

NOT 

applicable 

NOT 

APPLICABLE 

NOT 

APPLICABLE 

NOT 

APPLICABLE 

NOT 

APPLCABLE 

NOT 

APPLCABLE 

NOT 

APPLCABLE 

NOT 

APPLCABLE 

REOUIRED 

CONTRACTOR 

REOUIRED 

CONTRACTOR 

REOUIRED 

CONTRACTOR 

REOUIRED 

CONTRACTOR 

REOUIRED 
SUPPORT  activity 

REOUIRED 
SUPPORT  ACTIVITY 
REOUIRED 
SUPPORT  ACTIVITY 

REOUIRED 
SUPPORT  ACTIVITY 

TASK  107 

Indentured  Listing 

NOT 

APPLICABLE 

NOT 

APPLCABLE 

REOUIRED 

CONTRACTOR 

REOUIRED 
SUPPORT  ACTIVITY 

TASK  111 

Program  Cons  acts 

RECOMMENDED 
BUYING  ACTIVITY 

RECOMMENDED 
BUYING  ACTIVITY 

RECOMMENDED 
BUYING  ACTIVITY 

mhbm 

TASK  201 

Changes  in  Process 

REOUIRED 
BUYING  ACTIVITY 

REOUIRED 
BUYING  ACTIVITY 

REOUIRED 
BUYUG  ACTIVITY 

REOUIREO 
SUPPORT  ACTIVITY 

TASK  202 

TASK  211 

Change  History 

Change  Event  Dale 

RECOMMENOED 
BUYING  ACTIVITY 
NOT 

RECOMMENOED 
BUYING  ACTIVITY 

RECOMMENDED 
BUYING  ACTIVITY 

recommended 

BUYING  ACTIVITY 

RECOMMENDED 
BUYHG  ACTIVITY 

RECOMMENDED 
BUYING  ACTIVITY 

RECOMMENDED 
SUPPORT  ACTIVITY 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  212 

Change  Event  History 

NOT 

RECOMMENOED 
BUYING  ACTIVITY 

RECOMMENDED 
buy*vg  activity 

RECOMMENDED 
BUYING  ACTIVITY 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  213 

Daie  Search 

NOT 

RECOMMENDED 
BUYING  ACTIVITY 

RECOMMENDED 
BUYING  ACTIVITY 

RECOMMENDED 
BUYING  ACTIVITY 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  301 

Approved  Changes 

WOlMMD 

rrTt**»L/e»c  aCTtYTTr  O* 

NfOlMfO 

im<a»LrrNO  BCrwrrr  am 

frrw **/*«<,  •cTNmro* 
CO*T»*CTO* 

REOUIRED 
SUPPORT  ACTIVITY 

TASK  401 

Approved  Change  Implement 

RECOMMENDED 
buying  activity 

RECOMMENDEO 

CONTRACTOR 

REOUIRED 

CONTRACTOR 

REOUIRED 
SUPPORT  ACTIVITY 

TASK  411 

Specification 

OPTIONAL 
BUYING  ACTIVITY 

optional 

CONTRACTOR 

OPTIONAL 

CONTRACTOR 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  412 

Drawing 

NOT  APPLICABLE 

NOT  APPLICABLE 

optional 

CONTRACTOR 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  413 

Software 

NOT  applicable 

NOT  APPLCABLE 

OPTIONAL 

CONTRACTOR 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  414 

T  echnical  Manual 

NOT  APPLICABLE 

NOT  APPLCABLE 

optional 

CONTRACTOR 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  415 

Sparas  Purchase 

NOT  APPLCA8LE 

NOT  APPLCABLE 

OPTIONAL 

contractor 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  416 

Support  Equipment 

NOT  APPL  CABLE 

NOT  APPLCABLE 

OPTIONAL 

CONTRACTOR 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  41 7 

Retrofit  Kit  Development 

NOT  APPLICABLE 

NOT  APPLICABLE 

OPTIONAL 
SUPPORT  ACTIVITY 

TASK  501 

A*  Built  Record 

not  applicable 

NOT  APPLCABLE 

REQUIRED 

CONTRACTOR 

NOT  APPLICABLE 

TASK  502 

Maintenance  History 

NOT  APPLICABLE 

NOT  APPLCABLE 

REOUIRED 
SUPPORT  ACTIVITY 

REOUIREO 
SUPPORT  ACTIVITY 

TASK  503 

Retrplit  History 

NOT  APPLCABLE 

NOT  APPLCABLE 

REQUIRED 

REOUIRED 

SUPPORT  ACTIVITY 

TASK  601 

TASK  602 

Audtt  Acton  ham  Status 

Audit  Acton  Ram  History 

NOT  APPLCABLE 

NOT  APPLICABLE 

REOUIRED 
BUYING  ACTIVITY 
OPTIONAL 

REOUIRED 
BUYING  ACTIVITY 

optional 

AS  APPROPRIATE 
BUYING  ACTIVITY 
OPTIONAL 

BUYING  ACTIVITY 

BUYING  ACTIVITY 

BUYING  ACTIVITY 

6.3  Data  requirements. 

The  following  Data  Item  Descriptions  must  be  listed,  as  applicable,  on  the  Contract  Data  Requirements  List 
(DD  Form  1423)  when  this  standard  is  applied  on  contract,  in  order  to  obtain  the  data,  except  where  DOD  FAR 
Supplement  27.475-1  exempts  the  requirement  for  a  DD  Form  1423. 
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Table  6.3-1  DIDs 


Reference  Paragraph 

DID  Number 

DID  Title 

5.2.1. 

DI-CMAN-80858B 

Contractor’s  CM  Plan 

5. 3. 5.2.1 

DI-CMAN-80463C 

Engineering  Release  Record 

5.3.7. 1 

DI-CMAN-81248A 

Interface  Control  Drawing  Documentation 

DI-CMAN-80639C 

Engineering  Change  Proposal 

5.4.2.4.1, 

5.4. 8.2.1 

5.4.3.4 

DI-CMAN-80640C 

Request  for  Deviation 

5.4. 8.3. 3 

5.4. 8.4. 3 

5.4.6 

DI-CMAN-80643C 

Specification  Change  Notice 

5.4.7 

DI-CMAN-80642C 

Notice  of  Revision 

5.5.5 

DI-CMAN-81253A 

Configuration  Status  Accounting  Information 

5.5.8 

DI-CMAN-81245A 

Installation  Completion  Notification 

5.6.1.2 

DI-ADMN-81249A 

Conference  Agenda 

5.6.1.2 

DI-ADMN-81250A 

Conference  Minutes 

5. 6.2. 5 

DI-CMAN-81022C 

Configuration  Audit  Summary 

5. 6. 3. 5  Report 

The  above  DIDs  are  those  cleared  as  of  the  date  of  this  TOR. 

The  current  issue  of  DOD  5010. 12-L,  Acquisition  Management  Systems  and  Data  Requirements  Control  List 
(AMSDL)  must  be  researched  to  ensure  that  only  current,  cleared  DIDs  are  cited  on  the  DD  Form  1423. 

6.4  Superseded  data. 

The  following  military  standards  are  cancelled  and  replaced  with  this  TOR.  MIL-STD-973: 

MIL-STD-480 

MIL-STD-481 

MIL-STD-482 

MIL-STD-483 

MIL-STD-973 

MIL-STD-1456 
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6.5  Subject  term  (key  word)  listing. 

Baseline 

Configuration  audit 
Configuration  control 
Configuration  control  board 
Configuration  documentation 
Configuration  identification 
Configuration  item 
Configuration  management  plan 
Configuration  status  accounting 
Computer  software  configuration  item 
Developmental  configuration 
Deviation/Request  for  Deviation 
Effectivity 

Engineering  change  proposal 
Engineering  release 
Hardware  configuration  item 
Interface  control 
Interface  control  working  group 
N  on-developmental  item 
Notice  of  Revision 
Specification  Change  Notice 
Version 

Work  breakdown  structure 

6.6  Useful  references. 

•  CAGE  Codes  are  provided  in  Defense  Logistic  Agency  (DLA)  Cataloging  Handbook  H4/H8  Series. 
(See  3.8) 

•  Requirements  associated  with  distribution  statements  for  technical  data  should  be  contained  in  the 
SOW  or  CDRL  (See  4.3.1) 

•  Requirements  associated  with  Work  Breakdown  Structures  (WBSs)  are  provided  in  MIL-HDBK-881, 
“Work  Breakdown  Strictures  for  Defense  Materiel  Items.”  WBSs  will  normally  be  contractually 
invoked  in  development  contracts  only.  (See  5.2.2) 

•  Specification  identifiers  and  procedures  associated  with  changes  to  specifications  are  contained  in 
MIL-  STD-961,  “Military  Specifications  and  “  Associated  Documents,  Preparation  of.”  Similar 
material  associated  with  engineering  drawings,  associated  lists  and  ancillary  documents  is  contained  in 
ASME  Y  14.100  “Engineering  Drawing  Practices.  “  (See  5. 3. 6. 3) 

•  Part/item  identification  numbers  are  addressed  in  ASME  Y  14.  lOOand  MIL-STD-961.  (See  5. 3. 6. 4) 

•  CIs,  including  component  parts,  assemblies,  units,  sets  and  other  pieces  of  military  property  are  often 
marked  with  their  identifiers  in  accordance  with  MIL-STD-130,  “Identification  Marking  of  US 
Military  Property;”  or  with  identification  plates/nameplates  in  accordance  with  MIL-P- 15024,  “Plates, 
Tags  and  Bands  for  Identification  of  Equipment.  ”  (See  5. 3. 6. 7) 

•  Requirements  associated  with  a  system  hazard  analysis  are  contained  in  MIL-STD-882,  “System 
Safety  Program  Requirements”.  (See  5.4.2. 3.2g) 

•  Requirements  associated  with  the  DoD  Parts  Control  Program  are  contained  in  MIL-STD-965,  “Parts 
Control  Program.  ”  (See5.6.3.3d) 

•  Requirements  associated  with  logistics  support  analysis  (LSA)  tasks  are  contained  in  MIL-STD-1388- 
1,  “Logistic  Support  Analysis”  and  requirements  associated  with  LSA  data  are  contained  in  MIL-STD 
-1388-2,  “DoD  Requirements  for  a  Logistic  Support  Analysis  Record.  ”  (See  D.5.3.3c) 
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APPENDIX  A 


FCA  AND  PCA  CERTIFICATION  DOCUMENTATION 
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AUDIT  ACTION  ITEM  LIST  -  PART  I 


PROBLEM  IDENTIFICATION 


FCA:  PCA: 

Control  No.: 

Contractor: 

Contract  Number: 

Cage  Code: 

Action  Item  Originator 

Name: 

Phone: 

Organization: 

Identification  of  Item  being  Audited 

Configuration  Item  Nomenclature: 

Part  Number: 

Serial  Number: 

Subelement  Affected: 

Contract  Requirement(s)  Affected: 

Document 

Page 

Paragranh 

Narrative  Description  of  Problem: 

Alternative  Approach  (Optional): 

Forwarded  by: 

Group  Leader 

Team  Leader 

AUDIT  ACTION  ITEM  LIST  -  PART  II 


PROBLEM  RESOLUTION 


FCA:  PCA:  Control  No.: 

Contractor’s  Response: 


□  OPEN  (Follow-up  action  required) 


[  ~  ]  CLOSED  (No  follow-up  required) 


FIRST  ACTION 


Assigned  to: 


Suspense: 


SECOND  ACTION 


Assigned  to: 


Suspense: 


Concurrence  Signatures: 

Contractor  Government 


Resolution 


Government  Action  Item  Closeout 
Name  Signature  Date 

Originator  Audit  Team  _  _ 

Government  _  _ 

Contractor 


FCA  CHECKLIST 


Nomenclature:  _ 

Cl  Identifier:  Date: 


Contractor  Requirements 

Yes 

No 

1 .  Deviation  List  Prepared 

2.  Verification  Test  Procedures  Submitted 

3.  Verification  Testing  Completed 

4.  Verification  Test  Results  Compiled  and  Available 

5.  Facilities  for  Conducting  FCA  Available 

6.  Verification  Test  Procedures  Reviewed  and  Approved 

7.  Verification  Testing  Witnessed 

8.  Verification  Test  Data  Results  Reviewed  and  Approved 

Comments: 


FCA  CERTIFICATION  PACKAGE 


for 


Cl  IDENTIFIER(s): 
CONTRACT  NO. 


Prime  Contractor: 


Equipment  Manufacturers: 


Approved  by: 

Approved  by: 

(Contractor) 

(Government) 

Date: 

Date: 

FCA  CERTIFICATION  PACKAGE 


SCOPE / PURPOSE 


PURPOSE: 

The  purpose  of  this  FCA  was  to  verify  that  the  configuration  item’s  performance  complied  with  the  Development 
Specification. 


FCA  CERTIFICATION  PACKAGE 


SHEET  NO.  1 


(for  Equipment/Computer  Software) 


Contract:  _  Date: 

Contractor:  _ 

Cl  Identifier: 


Verification  Test  Procedures  and  Results.  The  verification  test/analysis  results  have  been  reviewed  to  ensure  that 
testing  is  adequate,  properly  done,  and  certified.  (All  test  procedures  and  interface  documents  shall  be  reviewed  to 
assure  that  the  documents  have  been  approved  by  the  Government.  All  test  data  sheets  shall  be  reviewed  to  assure 
that  the  test  was  witnessed  by  a  representative  of  the  Government.) 

Attached  is  a  list  of  the  documents  reviewed. 

Check  one. 

□  Procedures  and  results  reviewed  satisfy  the  requirements  and  are  accepted.  See  Attachment 
for  comments. 

□  Attached  is  a  list  of  deficiencies. 

Signature(s)  of  FCA  Team  Member(s): 

* 


*Sub-Team  Chairperson 


FCA  CERTIFICATION  PACKAGE 


SHEET  NO.  2 


(for  Equipment/Computer  Software) 


Contract:  _  Date: 

Contractor:  _ 

Cl  Identifier: 


Review  of  Deviations.  A  review  of  all  deviations  to  military  specifications  and  standards  that  have  been  approved. 
The  purpose  is  to  determine  the  extent  to  which  the  equipment/computer  software  undergoing  FCA  vary  from  one 
application  specifications  and  standards  and  to  form  a  basis  for  satisfactory  compliance  with  these  specifications  and 
standards.  In  accordance  with  this  paragraph,  all  applicable  deviations  have  been  reviewed  with  the  following  results: 

Check  one. 

r~j  The  equipment/computer  software  listed  on  Certification  Sheet  No.  1  of  this  report  complies  with  all 
applicable  specifications  and  standards.  See  Attachment _ for  comments. 

□  Attached  is  a  summary  of  FCA  discrepancies. 

Signature(s)  of  FCA  Team  Member(s): 

* 


*Sub-Team  Chairperson 

A.  Deviation  Review  Team  Instructions.  All  approved  deviations  to  military  specifications  and  standards  shall  be 
reviewed  and  recorded.  Also,  record  any  part  of  the  FCA  which  fails  to  meet  specifications  or  standards  but  is 
not  an  approved  deviation. 

B.  Results  of  Team  Review.  List  the  deviations  against  the  equipment/computer  software  being  FCA’d  that  were 
reviewed. 


FCA  CERTIFICATION  PACKAGE 


DEFICIENCY  SUMMARY  LIST 


Configuration  Item  Nomenclature: 


Responsibility  for 

Cl  Identifier 

Report  Reference 

Description 

Correction 

Place  of  Inspection 

Inspected  By 

FCA  CERTIFICATION  PACKAGE 


SPECIFICATION  /  TESTING  REVIEW 


Configuration  Item  Nomenclature: 

Specification  Number: 

Test  Procedures: 

Spec  Ref 

TP  Ref 

Description  Test  Result 

FCA  CERTIFICATION  PACKAGE 


FCA  DEVIATIONS 


Configuration  Item  Nomenclature: 


Reference 

CCB  or  MRB 

(Spec,  STD,  etc.) 

Approval  /  Directive 

Requirement  Waived 

Remarks 

PCA  CHECKLIST 


The  following  hardware,  computer  software,  and  documentation  shall  be  available,  and  the  following 
tasks  shall  be  accomplished,  at  the  PCA. 


HARDWARE: 

COMPUTER  software: 
documentation: 

Yes  NO 

1 .  Approved  final  draft  of  the  configuration  item  product  specification. 

2.  A  list  delineating  both  approved  and  outstanding  changes  against  the  configuration  item. 

3.  Complete  shortage  list. 

4.  Acceptance  test  procedures  and  associated  test  data. 

5.  Engineering  Drawing  Index. 

6.  Operating,  maintenance,  and  illustrated  parts  breakdown  manuals. 

7.  List  of  approved  material  review  board  actions  on  deviations. 

8.  Proposed  DD  Form  250  -  “Material  Inspection  and  Receiving  Report.” 

9.  Approved  nomenclature  and  nameplates. 

10.  Manuscript  copy  of  all  software  Cl  manuals. 

11.  Computer  Software  Version  Description  Document. 

12.  Current  set  of  listings  and  updated  design  descriptions,  or  other  means  of  design  portrayal,  for  each 
software  CL 

13.  FCA  minutes  for  each  configuration  item. 

14.  Program  Parts  Selection  List  (PPSL)  (see  MIL-STD-965). 


tasks:  Yes  No 

1 .  Define  Product  Baseline. 

2.  Specification  Review  and  Validation. 

3.  Drawing  Review. 

4.  Review  acceptance  test  procedures  and  results. 

5.  Review  shortages  and  unincorporated  design  changes. 

6.  Review  deviations. 

7.  Examine  proposed  DD  250. 

8.  Review  contractor’s  Engineering  Release  and  Change  Control  System. 

9.  Review  system  allocation  document. 

10.  Review  Software  User’s  Manuals,  Software  Programmer’s  Manuals,  Computer  System  Operator’s 
Manual,  and  Firmware  Support  Manual. 

11.  Review  software  CIs  for  the  following: 

a.  Preliminary  and  detail  Software  Component  design  descriptions. 

b.  Preliminary  and  detail  Software  interface  requirements. 

c.  Database  characteristics,  storage  allocation  charts,  and  timing  and  sequencing  characteristics. 

12.  Review  packaging  plan  and  requirements. 

13.  Review  status  of  Rights  in  Data. 

14.  Ensure  that: 

a.  All  appropriate  items  installed  in  the  deliverable  hardware  (that  should  have  been  processed 
through  the  PCP)  are  identified  on  the  PPSL,  or  the  necessary  approval  documentation  is  available. 

b.  The  hardware  does  not  contain  items  that  should  have  been  processed  through  the  PCP  but  were 
not.  (See  MIL-STD-965.) 


PCA  CERTIFICATION  PACKAGE 


CI  IDENTIFIER: 

CONTRACT  NO. 


Prime  Contractor: 


Eauinment  Manufacturers: 


PCA  CERTIFICATION  PACKAGE 


SCOPE / PURPOSE 


PCA  CERTIFICATION  PACKAGE 


SHEET  NO.  1 

(for  Equipment/Computer  Software) 

Contract:  _  Date: 

Contractor: 


Product  Baseline.  The  following  documents  of  the  issue  and  date  shown  comprise  the  product  baseline  for  the  listed 
equipment/computer  software. 


**  Team  Chairperson 
*  Sub-Team  Chairperson 


PCA  CERTIFICATION  PACKAGE 
SHEET  NO.  2 

(for  Equipment/Computer  Software) 


Contract:  _  Date: 

Contractor: 


Specification  Review  and  Validation.  Specifications  have  been  reviewed  and  validated  to  assure  that  they 
adequately  define  the  configuration  item  and  the  necessary  testing,  mobility/transportability  and  packaging 
requirements. 

Check  one. 

|  |  The  Product  Specifications  are  complete  and  adequately  define  the  configuration  item.  They 
will,  therefore,  constitute  the  product  baseline.  See  attachment _ for  comments. 

I  I  The  Product  Specifications  are  unacceptable.  See  attachment _ for  a  list  of  discrepancies. 


Signature(s)  of  PCA  Team  Member)  s): 


** 


* 


**  Team  Chairperson 
*  Sub-Team  Chairperson 


A.  Specification  Review  and  Validation  Instructions.  The  detailed  specifications  listed  in  paragraph  B  below 
shall  be  reviewed  for  compliance  with  the  applicable  requirements.  Each  specification  shall  serve  as  the 
basic  document  for  configuration  control  of  the  subject  configuration  items.  The  information  contained 
within  the  specifications  will  be  audited  at  the  PCA. 

B.  Review  and  Validation  Results. 


1 .  Specifications  reviewed  and  validated: 
Spec.  No.  Part  No, 


Equipment/Computer 

Date  Software  Nomenclatures 


2.  Specifications  reviewed  and  disapproved:  (Provide  attachment  for  causes.) 
Spec.  No.  Part  No,  Date 


Equipment/Computer 
Software  Nomenclatures 


PCA  CERTIFICATION  PACKAGE 
SHEET  NO.  3 

(Equipment) 


Contract: 

Contractor: 


Drawing  Review.  Drawings  have  been  compared  with  the  equipment  to  ensure  that  the  latest  drawing 
change  letter  has  been  incoiporated  into  the  equipment,  that  part  numbers  agree  with  the  drawings,  and  that 
the  drawings  are  complete  and  accurately  describe  the  equipment. 

Check  one. 

|  |  The  drawings  are  complete  and  accurately  describe  the  equipment.  See  attachment _ for 

comments. 

|  |  The  drawings  are  compatible  with  the  applicable  contract  Program  Parts  Selection  List 
(PPSL). 


|  |  Attachment _ is  a  list  of  discrepancies. 


Signature(s)  of  PCA  Team  Member(s): 


Sub-Team  Chairperson 


Drawing  Review  Results.  The  following  drawings  were  reviewed  by  the  PCA  drawing  review  sub-teams: 


DOCUMENT  NUMBER 


DOCUMENT  TITLE 


PCA  CERTIFICATION  PACKAGE 
SHEET  NO.  4 

(Equipment) 


Contract:  _  Date: 

Contractor: 


Acceptance  Test  Procedures  and  Results.  The  acceptance  test  procedures  have  been  reviewed  for  adequacy, 
and  the  acceptance  test  results  have  been  reviewed,  to  ensure  that  the  testing  has  been  properly  done  and 
certified. 

Attachment _ is  a  list  of  the  documents  reviewed. 

Check  one. 

[  J  Procedures  and  results  reviewed  satisfy  the  requirements  and  are  accepted.  See  attachment 
for  comments. 

I  |  Attachment _ is  a  list  of  discrepancies. 

Siqnaturc(s)  of  PCA  Team  Member) s): 

** 

* 


*  Sub-Team  Chairperson 

A.  Acceptance  Test  Procedures.  The  following  acceptance  test  procedures  were  reviewed  by  the 
ATP  Sub-Team: 

Document  Number  Date/Rev.  Ltr.  Document  Title  Status 


B.  Acceptance  Test  Results.  The  following  acceptance  test  results  documentation  was  reviewed  by 
the  ATR  Sub-Team: 

Document  Number  Date/Rev.  Ltr.  Document  Title  Status 


PCA  CERTIFICATION  PACKAGE 
SHEET  NO.  5 

(for  Equipment/Computer  Software) 


Contract:  _  Date: 

Contractor: 


REVIEW  OF  SHORTAGES  AND  UNINCORPORATED  DESIGN  CHANCES 

The  shortages  and  unincorporated  design  changes  listed  on  the  proposed  DD  Form  250,  “Material  Inspection 
and  Receiving  Report,”  and  other  records,  have  been  reviewed. 

Check  one. 

|  |  There  are  no  shortages  or  unincorporated  design  changes. 

|  |  Attachment _ is  a  list  of  shortages  and/or  unincorporated  design  changes,  and  the 

recommended  corrective  action  required. 

Signature(s)  of  PCA  Team  Member(s): 


*  Sub-Team  Chairperson 

A.  Review  of  Shortages  and  Unincorporated  Design  Changes. 

All  shortages  and  unincorporated  design  changes  listed  on  the  proposed  DD  Form  250,  “Material 
Inspection  and  Receiving  Report,”  shall  be  reviewed  by  the  Government  or  their  designated 
representatives  for  a  determination  of  what  changes  should  be  accomplished  in  the  field  and  what  changes 
should  be  accomplished  at  the  contractor’s  facility.  The  Government  shall  also  determine  if  the  reported 
shortages  and  unincorporated  changes  are  complete. 

B.  Results 

List  the  shortages  and  unincorporated  design  changes  that  were  reviewed  in  compliance  with 
requirements,  including  the  agreed-to  corrective  action. 


PCA  CERTIFICATION  PACKAGE 
SHEET  NO.  6 

(for  Equipment/Computer  Software) 


Contract:  _  Date: 

Contractor: 


REVIEW  DEVIATIONS 

A  review  of  all  deviations  to  military  specifications  and  standards  that  have  been  approved.  The  purpose  is  to 
determine  the  extent  to  which  the  equipment/computer  software  undergoing  PCA  varies  from  applicable 
specifications  and  standards  and  to  form  a  basis  for  satisfactory  compliance  with  these  specifications  and 
standards. 

Check  one. 

Q  The  equipment/computer  software  listed  on  Certification  Sheet  No.  1  of  this  report  complies 
with  all  applicable  specifications  and  standards.  See  attachment _ for  comments. 

I  I  Attachment _ is  a  list  of  discrepancies  and/or  comments. 

In  accordance  with  this  paragraph,  all  applicable  deviations  have  been  reviewed  with  the  following 
results: 

Signature(s)  of  PCA  Team  Member(s): 

* 


*  Sub-Team  Chairperson 
Deviation  Review  Team  Instructions. 

All  approved  deviations  to  military  specifications  and  standards  shall  be  reviewed  and  recorded.  Also,  record 
any  part  of  the  PCA  that  fails  to  meet  specifications  or  standards  but  is  not  an  approved  deviation. 

Results  of  Team  Review. 

List  the  reviewed  deviations  against  the  equipment/computer  software  being  PCA’d. 


PCA  CERTIFICATION  PACKAGE 
SHEET  NO.  7 

(for  Equipment/Computer  Software) 


Contract:  _  Date: 

Contractor: 


EXAMINATION  OF  THE  PROPOSED  DP  FORM  250. 

The  DD  Form  250  has  been  examined  to  ensure  that  it  adequately  defines  the  equipment/computer  software 
and  that  unaccomplished  tasks  are  included  as  deficiencies. 

Check  one. 

The  DD  Form  250  adequately  defines  the  equipment/computer  software  and  all 
unaccomplished  tasks  are  included  as  deficiencies. 

I  I  Attachment _ is  a  list  of  discrepancies  and/or  comments. 


Signature(s)  of  PCA  Team  Member(s): 

* 


*  Sub-Team  Chairperson 

A.  Examination  of  Proposed  DD  Form  250. 

The  proposed  DD  Form  250  shall  be  examined  for  completeness  and  an  accurate  definition  of  the 
equipment/computer  software.  Unaccomplished  tasks,  shortages,  and  certain  specified  discrepancies 
uncovered  at  the  PCA  shall  be  included  in  the  DD  Form  250.  If  the  equipment/computer  software  is  to 
be  shipped  from  the  plant,  the  Program  Office  representative  will  recommend  to  the  Contract 
Administrative  Office  that  the  DD  Form  250  be  executed  in  accordance  with  the  terms  of  the  contract. 

B.  Results. 

Include  a  statement  that  the  proposed  DD  Form  250  was  examined  and  recommended. 


PCA  CERTIFICATION  PACKAGE 
SHEET  NO.  8 

(for  Equipment/Computer  Software) 


Contract:  _  Date: 

Contractor: 


REVIEW  OF  CONTRACTORS'  ENGINEERING  RELEASE  AND  CHANGE  CONTROL  SYSTEM. 

The  contractor’s  engineering  release  system  and  change  control  procedures  have  been  reviewed  to  ensure  that 
they  are  adequate  to  properly  control  the  processing  and  formal  release  of  engineering  changes. 

Check  one. 

j  1  The  contractor’s  engineering  release  system  and  change  control  procedures  are  adequate  for 
the  processing  and  formal  release  of  engineering  changes.  See  attachment _ for  comments. 

EH  Attachment _ is  a  list  of  deficiencies. 

Signature(s)  of  PCA  Team  Member(s): 

* 


*  Sub-Team  Chairperson 


PCA  CERTIFICATION  PACKAGE 
SHEET  NO.  9 

(for  Equipment/Computer  Software) 


Contract:  _  Date: 

Contractor: 


1.  REVIEW  OF  LOGISTICS  SUPPORT  PLAN  FOR  PRE-OPERATIONAL  SUPPORT. 

The  logistics  Support  Plan  for  Pre-operational  Support  has  been  reviewed  to  ensure  that  it  is  adequate  to 
support  the  acquisition  phase  and  is  compatible  with  the  operational  phase  maintenance  concept  and 
support  requirements. 


Check  one. 

The  contractor’s  Logistic  Plan  for  pre-operational  support  will  fulfill  the  acquisition  phase 
requirements  and  is  compatible  with  operational  phase  needs. 

Attachment  is  a  list  of  deficiencies. 


2.  farVlEW  OF  LONG  LEAD  TIME  ITEMS  AM)  PROVISIONED  H  EMS  PROC  ESSED  PRIOR  TO  PCA. 

Long  Lead  Time  items  released  and  items  provisioned  prior  to  PCA  have  been  reviewed  to  ensure  that 
obsolete  items  resulting  from  pre-PCA  design  changes  are  purged  from  the  system.  While  basic  items 
may  be  upgraded  by  rework  or  modification,  these  actions  have  been  verified  as  accomplished  or  in 
process,  based  upon  design  change  notice. 


Check  one. 

Long  lead  time  items,  and  provisioned  items  processed  prior  to  PCA,  are  all  of  current 
configuration  at  time  of  PCA  or  are  in  work. 

□  Attachment  is  a  list  of  deficiencies. 


Smnature(s)  of  PCA  Team  Member(s): 


* 


*  Sub-Team  Chairperson 


SMC  Standard  Improvement  Proposal 

INSTRUCTIONS 

1.  Complete  blocks  1  through  7.  All  blocks  must  be  completed. 

2.  Send  to  the  Preparing  Activity  specified  in  block  8. 

NOTE:  Do  not  be  used  to  request  copies  of  documents,  or  to  request  waivers,  or  clarification  of  requirements  on 
current  contracts.  Comments  submitted  on  this  form  do  not  constitute  or  imply  authorization  to  waive  any  portion  of 
the  referenced  document(s)  or  to  amend  contractual  requirements.  Comments  submitted  on  this  form  do  not 
constitute  a  commitment  by  the  Preparing  Activity  to  implement  the  suggestion;  the  Preparing  Authority  will 
coordinate  a  review  of  the  comment  and  provide  disposition  to  the  comment  submitter  specified  in  Block  6. 


SMC  STANDARD 

CHANGE 

RECOMMENDATION: 

1.  Document  Number 

2.  Document  Date 

3.  Document  Title 

4.  Nature  of  Change 

(Identify  paragraph  number;  include  proposed  revision  language  and  supporting  data.  Attach  extra  sheets  as  needed.) 


5.  Reason  for  Recommendation 


6.  Submitter  Information _ _ 

a.  Name  b.  Organization 


c.  Address  d.  Telephone 


e.  E-mail  address  7.  Date  Submitted 


8.  Preparing  Activity  Space  and  Missile  Systems  Center 

AIR  FORCE  SPACE  COMMAND 
483  N.  Aviation  Blvd. 

El  Segundo,  CA  91245 
Attention:  SMC/EAE 


March  2008 


